One of them is really more about governance than engineering, although it mixes both. The Bitcoin model is “this thing exists, it has to work, we’re not going to screw with it unless there is overwhelming consensus to do so.” And in fact it is structurally pretty hard to screw with it, absent overwhelming consensus to do so; if you screw it up, you fork the chain. (Realistically, the core devs could probably force something through once, at great reputational cost; but both the core devs themselves, and the user community, are philosophically opposed to that kind of thing.)
Meanwhile, the Ethereum model seems to be “you run what the devs tell you to run.” If we want to change the rules, we change the rules. Most people don’t even run full nodes; they use a small number of major service providers. And incidents like this are scary: https://www.coindesk.com/ethereum-service-providers-experiencing-issues-after-reported-blockchain-split . The devs released new software that changed the rules; major service providers were not given advance notice and did not update; this broke a ton of stuff. Since the devs define the protocol, those service providers were then forced to update.
The last accidental hard fork of the Bitcoin chain, and the only one I’m aware of, was in 2013. https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki . It was due to a bug, and unlike the Ethereum scenario, the clear Bitcoin community consensus was to roll back to the version before the accidental break. Nobody in Bitcoin has the mandate to roll out a breaking change and force everybody to adopt it. (You can definitely argue about the various community splits on breaking change proposals in the past, but IMO this underscores that the community’s view of a change IS the critical determining factor; the devs can’t just release a breaking change and expect everybody to go along, whereas in Ethereum that’s the norm.)
From a more engineering-oriented and less governance-oriented view, I guess my main concern is that Ethereum’s scripting model is very complicated compared to Bitcoin’s. I’m not aware of a Bitcoin script ever being hacked, granted that this is because Bitcoin scripts are much less capable than Ethereum scripts! Meanwhile, here is a list of Ethereum smart contract postmortems: https://forum.openzeppelin.com/t/list-of-ethereum-smart-contracts-post-mortems/1191 . It’s a long list.
The worst one I’m aware of is https://www.parity.io/security-alert-2/ . Parity was/is one of the first-party, supported, officially-sanctioned Ethereum nodes/wallets. (It’s hard for me to tell whether it’s currently the recommended full node to run yourself, because the Ethereum website does not recommend ANY full node software to run yourself, that I can see; only light wallets and third-party hosted wallets. One of the recommended open-source Bitcoin wallets, Bitcoin Core, is a full node.)
In the linked incident, ALL PARITY MULTISIG WALLETS AND THEIR CONTENTS WERE DESTROYED. (And I had forgotten, but that site reminds me, that this was actually the SECOND issue with Parity multisig wallets, and was introduced in the fix to a previous issue. The link to the previous issue is dead, so I don’t know whether that also resulted in loss of all funds.)
This isn’t a detailed or exhaustive investigation, and of course not all of this can be blamed on Ethereum itself. But generally I would say that my impression is that Ethereum has lower engineering standards than Bitcoin does.
For an example of good engineering on the Bitcoin side: Some Bitcoin devs did exhaustive testing of some of Bitcoin’s cryptograpy against OpenSSL, in order to check for bugs in the Bitcoin code. Instead, they found a bug in OpenSSL: https://www.openssl.org/news/secadv/20150108.txt (search-in-page for “squaring”.) Obviously there could be stuff like this in the Ethereum camp, too, and I wouldn’t necessarily know since I mostly only deal with Bitcoin.
The Bitcoin model is “this thing exists, it has to work, we’re not going to screw with it unless there is overwhelming consensus to do so.” And in fact it is structurally pretty hard to screw with it, absent overwhelming consensus to do so;
With the majority of the mining power concentrated in China I don’t think that’s really true. China could just pass a law that says: “It’s illegal to sign blocks that contain transfered funds of terrorist entities, the Chinese government is able to decide to freeze certain addresses so that Chinese miners are not allowed to accept blocks (optionally: that are newer then two days) or create blocks that move funds out of those addresses”.
Without a fork that would mean that the Chinese miners are able to have the longest blockchain and thus the official one. I don’t see an easy way to fork and invalidate the ability for the Chinese miners to do that either. You would likely need to do things like changing the underlying signing algorithms to invalidate the ASICs.
From a more engineering-oriented and less governance-oriented view, I guess my main concern is that Ethereum’s scripting model is very complicated compared to Bitcoin’s. I’m not aware of a Bitcoin script ever being hacked, granted that this is because Bitcoin scripts are much less capable than Ethereum scripts!
You need the complicated scripts to do the complex DeFi stuff. If a substantial amount of the value of cryptocurrency comes out of the DeFi stuff that will likely mean that a crypto network that allows that stuff will move to the top.
That makes it sound like nobody lost Bitcoin in hacks either. I don’t see much difference between Binance losing 40$ million worth of Bitcoin in a hack of their software to a smart contract on the Ethereum network being hacked.
China could just pass a law that says: “It’s illegal to sign [certain blocks].
Without a fork that would mean that the Chinese miners are able to have the longest blockchain and thus the official one. I don’t see an easy way to fork and invalidate the ability for the Chinese miners to do that either. You would likely need to do things like changing the underlying signing algorithms to invalidate the ASICs.
I agree that you’re right about what would initially happen in this scenario (miner majority conspires to censor transactions).
It’s worth noting that you can only tighten restrictions this way, not loosen them (e.g. China can’t pass a law sending themselves all the coins, miner majority or not, without automatically forcing everyone else into a separate fork.)
The difficulty level of responding to this would depend on the policy goals of the Chinese government, and the level of coordination of the Chinese miners. If they were content to have their own China-Bitcoin fork, it would be easy enough to coordinate to let them go, and nothing as drastic as a PoW change would required. If not, it would certainly get messy, although I think we have some reasonable approaches prepared for this contingency, short of nuclear options.
If a substantial amount of the value of cryptocurrency comes out of the DeFi stuff that will likely mean that a crypto network that allows that stuff will move to the top.
I agree. Whether it’s worth the complexity is an interesting open question.
I don’t see much difference between Binance losing 40$ million worth of Bitcoin in a hack of their software to a smart contract on the Ethereum network being hacked.
Here I do see a tremendously large difference:
First of all, Binance is an exchange which trades both Bitcoin and Ethereum, and holds balances of both. The fact that they lost Bitcoin in the hack, and not Ether, is only because Bitcoin is more popular than Ethereum. There is zero structural advantage for Ethereum here.
Binance is a third-party website. I don’t know what standard practice in Ethereum is—hopefully the same—but it is strongly recommended in the Bitcoin community never to store coins with a third party. By contrast, Parity is one of the standard Ethereum local wallet apps, and the affected contract was the built-in multisig option in that app. “I gave my coins to a third party and they got lost” is very different from “I stored my coins in the official wallet app on my local computer and they got lost.”
Also, the amount in question was apparently ~7 times as large, in USD terms (or ~4x from another source): https://www.theguardian.com/technology/2017/nov/08/cryptocurrency-300m-dollars-stolen-bug-ether . And worse in market cap terms: this single bug destroyed about 1% of all Ether in existence (or 0.5%, according to a different source). The Binance hack represented about 0.03% of the Bitcoin in existence at that time.
In point of fact, Binance users did not lose funds—as far as I can tell, Binance covered all the losses. By contrast, in the Parity multisig incident, all affected user funds were—as far as I know—lost irrecoverably.
It’s also worth noting, if only for amusement value, that the Parity multisig issue was not technically a “hack”; the bug was triggered by accident, and the coins were lost (not taken). (Although the previous incident in the same contract, just 4 months prior was a theft.)
Obviously these points are applicable to these specific examples. There were other Ethereum contract losses where users did realistically know they were putting funds at risk, unlike the Parity incident. And there were other Bitcoin incidents where user funds did get lost, and were not returned (although of course they all involved storage of funds with third parties, not bugs in the standard client software, that I’m aware of.) But the sheer volume, severity, and general nature of the issues seems incomparable to me.
What do you mean when you say that that Ethereum has a weaker foundation, engineering-wise?
Hm, I guess I’m conflating two different things.
One of them is really more about governance than engineering, although it mixes both. The Bitcoin model is “this thing exists, it has to work, we’re not going to screw with it unless there is overwhelming consensus to do so.” And in fact it is structurally pretty hard to screw with it, absent overwhelming consensus to do so; if you screw it up, you fork the chain. (Realistically, the core devs could probably force something through once, at great reputational cost; but both the core devs themselves, and the user community, are philosophically opposed to that kind of thing.)
Meanwhile, the Ethereum model seems to be “you run what the devs tell you to run.” If we want to change the rules, we change the rules. Most people don’t even run full nodes; they use a small number of major service providers. And incidents like this are scary: https://www.coindesk.com/ethereum-service-providers-experiencing-issues-after-reported-blockchain-split . The devs released new software that changed the rules; major service providers were not given advance notice and did not update; this broke a ton of stuff. Since the devs define the protocol, those service providers were then forced to update.
The last accidental hard fork of the Bitcoin chain, and the only one I’m aware of, was in 2013. https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki . It was due to a bug, and unlike the Ethereum scenario, the clear Bitcoin community consensus was to roll back to the version before the accidental break. Nobody in Bitcoin has the mandate to roll out a breaking change and force everybody to adopt it. (You can definitely argue about the various community splits on breaking change proposals in the past, but IMO this underscores that the community’s view of a change IS the critical determining factor; the devs can’t just release a breaking change and expect everybody to go along, whereas in Ethereum that’s the norm.)
From a more engineering-oriented and less governance-oriented view, I guess my main concern is that Ethereum’s scripting model is very complicated compared to Bitcoin’s. I’m not aware of a Bitcoin script ever being hacked, granted that this is because Bitcoin scripts are much less capable than Ethereum scripts! Meanwhile, here is a list of Ethereum smart contract postmortems: https://forum.openzeppelin.com/t/list-of-ethereum-smart-contracts-post-mortems/1191 . It’s a long list.
The worst one I’m aware of is https://www.parity.io/security-alert-2/ . Parity was/is one of the first-party, supported, officially-sanctioned Ethereum nodes/wallets. (It’s hard for me to tell whether it’s currently the recommended full node to run yourself, because the Ethereum website does not recommend ANY full node software to run yourself, that I can see; only light wallets and third-party hosted wallets. One of the recommended open-source Bitcoin wallets, Bitcoin Core, is a full node.)
In the linked incident, ALL PARITY MULTISIG WALLETS AND THEIR CONTENTS WERE DESTROYED. (And I had forgotten, but that site reminds me, that this was actually the SECOND issue with Parity multisig wallets, and was introduced in the fix to a previous issue. The link to the previous issue is dead, so I don’t know whether that also resulted in loss of all funds.)
This isn’t a detailed or exhaustive investigation, and of course not all of this can be blamed on Ethereum itself. But generally I would say that my impression is that Ethereum has lower engineering standards than Bitcoin does.
For an example of good engineering on the Bitcoin side: Some Bitcoin devs did exhaustive testing of some of Bitcoin’s cryptograpy against OpenSSL, in order to check for bugs in the Bitcoin code. Instead, they found a bug in OpenSSL: https://www.openssl.org/news/secadv/20150108.txt (search-in-page for “squaring”.) Obviously there could be stuff like this in the Ethereum camp, too, and I wouldn’t necessarily know since I mostly only deal with Bitcoin.
With the majority of the mining power concentrated in China I don’t think that’s really true. China could just pass a law that says: “It’s illegal to sign blocks that contain transfered funds of terrorist entities, the Chinese government is able to decide to freeze certain addresses so that Chinese miners are not allowed to accept blocks (optionally: that are newer then two days) or create blocks that move funds out of those addresses”.
Without a fork that would mean that the Chinese miners are able to have the longest blockchain and thus the official one. I don’t see an easy way to fork and invalidate the ability for the Chinese miners to do that either. You would likely need to do things like changing the underlying signing algorithms to invalidate the ASICs.
You need the complicated scripts to do the complex DeFi stuff. If a substantial amount of the value of cryptocurrency comes out of the DeFi stuff that will likely mean that a crypto network that allows that stuff will move to the top.
That makes it sound like nobody lost Bitcoin in hacks either. I don’t see much difference between Binance losing 40$ million worth of Bitcoin in a hack of their software to a smart contract on the Ethereum network being hacked.
I agree that you’re right about what would initially happen in this scenario (miner majority conspires to censor transactions).
It’s worth noting that you can only tighten restrictions this way, not loosen them (e.g. China can’t pass a law sending themselves all the coins, miner majority or not, without automatically forcing everyone else into a separate fork.)
The difficulty level of responding to this would depend on the policy goals of the Chinese government, and the level of coordination of the Chinese miners. If they were content to have their own China-Bitcoin fork, it would be easy enough to coordinate to let them go, and nothing as drastic as a PoW change would required. If not, it would certainly get messy, although I think we have some reasonable approaches prepared for this contingency, short of nuclear options.
I agree. Whether it’s worth the complexity is an interesting open question.
Here I do see a tremendously large difference:
First of all, Binance is an exchange which trades both Bitcoin and Ethereum, and holds balances of both. The fact that they lost Bitcoin in the hack, and not Ether, is only because Bitcoin is more popular than Ethereum. There is zero structural advantage for Ethereum here.
Binance is a third-party website. I don’t know what standard practice in Ethereum is—hopefully the same—but it is strongly recommended in the Bitcoin community never to store coins with a third party. By contrast, Parity is one of the standard Ethereum local wallet apps, and the affected contract was the built-in multisig option in that app. “I gave my coins to a third party and they got lost” is very different from “I stored my coins in the official wallet app on my local computer and they got lost.”
Also, the amount in question was apparently ~7 times as large, in USD terms (or ~4x from another source): https://www.theguardian.com/technology/2017/nov/08/cryptocurrency-300m-dollars-stolen-bug-ether . And worse in market cap terms: this single bug destroyed about 1% of all Ether in existence (or 0.5%, according to a different source). The Binance hack represented about 0.03% of the Bitcoin in existence at that time.
In point of fact, Binance users did not lose funds—as far as I can tell, Binance covered all the losses. By contrast, in the Parity multisig incident, all affected user funds were—as far as I know—lost irrecoverably.
It’s also worth noting, if only for amusement value, that the Parity multisig issue was not technically a “hack”; the bug was triggered by accident, and the coins were lost (not taken). (Although the previous incident in the same contract, just 4 months prior was a theft.)
Obviously these points are applicable to these specific examples. There were other Ethereum contract losses where users did realistically know they were putting funds at risk, unlike the Parity incident. And there were other Bitcoin incidents where user funds did get lost, and were not returned (although of course they all involved storage of funds with third parties, not bugs in the standard client software, that I’m aware of.) But the sheer volume, severity, and general nature of the issues seems incomparable to me.