The Ethereum VS Bitcoin Fork

[Pmalek]

One thing has been on my mind for a long time, and I wanted to talk about it here with the community.

So, let’s start from the beginning.

In August 2010, a hacker discovered a bug in Bitcoin’s codebase that allowed him to generate 184 billion bitcoins. These coins were sent to two different addresses that received 92 billion each in the famous block #74,638.

This would later become known as the overflow bug.

Information about this particular case can be found on the links below:
https://bitcointalk.org/index.php?topic=822.0
https://bitcointalk.org/index.php?topic=823.0
https://decrypt.co/39750/184-billion-bitcoin-anonymous-creator

Within 5 hours, Satoshi and the bitcoin developers rolled out a fix that patches the overflow bug incident.

Version 0.3.10 patches the block 74638 overflow bug.   http://bitcointalk.org/index.php?topic=823

The Linux version includes tcatm's 4-way SSE2 SHA-256 that makes generating faster on i5, i7 (with hyperthreading) and AMD CPU's.  Try the "-4way" switch to enable it and check if it's faster for you. 

Download from sourceforge:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.10/

SHA1 16645ec5fcdb35bc54bc7195309a1a81105242bb bitcoin-0.3.10-win32-setup.exe
SHA1 4f35ad7711a38fe8c880c6c9beab430824c426d3 bitcoin-0.3.10-win32.zip
SHA1 e3fda1ddb31b0d5c35156cacd80dee6ea6ae6423 bitcoin-0.3.10-linux.tar.gz
SHA1 b812ccff4881778b9090f7c0b0255bcba7b078ac bitcoin-0.3.10-macosx.zip

It is no longer necessary to delete blk*.dat.  The good block chain has overtaken the bad block chain, so you can just upgrade and it'll automatically reorg away the bad block chain.

A fork happened, and the blockchain was forked back to the state before block #74,638. Some blocks were invalidated, and all the transactions that were carried out were rolled back.   

Bitcoin survived and prospered into what we have today, and rightly so. Nobody seemed to have a problem because something that was supposed to be immutable (Bitcoin) became mutable for a bit.

Now to the second part of the story.

Six years later, in June 2016, we had the DAO hack. Over 3.5 million ether valued at $50 million were stolen from the DAO smart contract.
(https://www.coindesk.com/understanding-dao-hack-journalists) 

The days that followed created huge tensions within the Ethereum community that couldn’t be solved, so the blockchain had to fork and split into two. Those who believed in the immutability of Ethereum stayed with the original idea and called their new network Ethereum Classic. The majority supported the fork and stayed with Ethereum.

The reason the fork happened was to return the stolen funds, but the Ethereum Classic folks didn’t want any of that.


In my opinion, both the Bitcoin and Ethereum forks were carried out to benefit the communities.

1.   But why is it that one network is being criticised for not being immutable while the other isn’t?
2.   Why do people (including highly ranked Bitcointalk members) think of Ethereum Classic as the ‘real Ethereum’?
3.   If that is how it should be, shouldn’t we also have a ‘real Bitcoin’ where two addresses hold 92 billion coins each?
4.   Why is it not OK to perform a fork to refund stolen ether due to a buggy code, but it is OK to invalidate bitcoin blocks due to wrongly generated bitcoins? 
5.   Is bitcoin not attacked for the fork because the bug led to the creation of bitcoins much higher than the maximum supply?
6.   Would the opinions have been any different if a much lower number of coins were generated?

- Both forks fixed bugs in the codebase. One allowed to generate a huge number of bitcoins, the other to transfer big amounts of ether.

[1714740675]

1714740675

[1714740675]

1714740675

[1714740675]

1714740675

[oryhp]

Hi, I think this is a good question and a lot of people struggle to see the difference, including many Ethereum twitter influencers. Here's my interpretation of it

> 1.   But why is it that one network is being criticised for not being immutable while the other isn’t?

In the case of Bitcoin, the protocol did not work "by the spec" so the implementation was flawed and it needed to be fixed.


> 2.   Why do people (including highly ranked Bitcointalk members) think of Ethereum Classic as the ‘real Ethereum’?

Because in the DAO hack, the Ethereum network was worked exactly as designed. There should be no intervention to bailout people when they mess up things. This is the whole point of having a blockchain, you let it run and it's running. The only way to keep the network neutral is by having a network that doesn't care what is happening on it - who is transacting, who's getting scammed etc. That's not what the network should care about, these things should be solved outside of it or not solved at all.

> 3.   If that is how it should be, shouldn’t we also have a ‘real Bitcoin’ where two addresses hold 92 billion coins each?

No, because the fork was not Bitcoin, it had a different schedule than it should. By fixing this protocol implementation bug, I would say they actually forked to the real Bitcoin chain.

> 4.   Why is it not OK to perform a fork to refund stolen ether due to a buggy code, but it is OK to invalidate bitcoin blocks due to wrongly generated bitcoins?

The bug in the DAO hard fork was in a software that was written on the Ethereum network, the Ethereum itself was working as designed. Why should people not intervene? No one should be able to do a state transition on chain that doesn't have a valid signature. If we bypass the cryptographic signatures, what are we left with? Not much really.

> 5.   Is bitcoin not attacked for the fork because the bug led to the creation of bitcoins much higher than the maximum supply?

Exactly, it made the Bitcoin implementation derail from the spec.

> 6.   Would the opinions have been any different if a much lower number of coins were generated?

No. The implementation would not match the spec, so it would need to be fixed.


> Both forks fixed bugs in the codebase. One allowed to generate a huge number of bitcoins, the other to transfer big amounts of ether.

Not really, Bitcoin wasn't working and it was fixed. Ethereum was working and it was "fixed".

There's one big difference in the two forks. Bitcoin fork went back in time, but didn't add any invalid state transitions. This means that you can control whether something ends up on the network or not, but you can't really manipulate the state in any way you want. On the other hand, what Ethereum did is exactly this. The move on the Ethereum side is equivalent to adding "unsigned transactions" to the network in the name of others. This gives you a much bigger power than just reverting blocks. When you revert a block you can censor things. But if you can manipulate the database values without valid signatures, you can also end up with the same balance state as when "reverting blocks" by simply inserting invalid "inverse" transactions. But it's worse, you can do anything with these values, not just revert them, so you can take anyone's money and move it around. Did they do this? no, they set the values of the specific addresses they labeled as "bad", but again, the protocol shouldn't care. They introduced the human interpretation of the good and bad on the network.

You can check the main part of the DAO hard fork code here https://github.com/ethereum/go-ethereum/blob/master/consensus/misc/dao.go#L83 . Mutating the database values without valid signatures is a big no no if the protocol was working correctly.

[pooya87]

A fork happened, and the blockchain was forked back to the state before block #74,638. Some blocks were invalidated, and all the transactions that were carried out were rolled back.   

@oryhp gave an excellent reply I just want to add that the terminology here is wrong. Discarding invalid blocks is not called "roll back", it is simply discarding invalid blocks. And those blocks were NOT invalidated, they were already invalid.

Imagine if majority of full nodes hadn't updated to new versions that recognize and validate witnesses and a malicious miner mined a block that contained a transaction spending an arbitrary SegWit output without the signature. All those (semi) full nodes accept the block as valid (since they don't see or validate any witneses) while it is not actually valid. If the stupid miners (eg. doing SPV mining) built on top of that block without validating it we end up with a long and invalid chain that has to be discarded because it would be invalid. That doesn't change anything about immutability of the blockchain.

[figmentofmyass]

this is the crux of the issue:

> 5.   Is bitcoin not attacked for the fork because the bug led to the creation of bitcoins much higher than the maximum supply?

Exactly, it made the Bitcoin implementation derail from the spec.

> Both forks fixed bugs in the codebase. One allowed to generate a huge number of bitcoins, the other to transfer big amounts of ether.

Not really, Bitcoin wasn't working and it was fixed. Ethereum was working and it was "fixed".

everyone using the bitcoin network had opted in to a 21M coin limit on a fixed emission schedule. this is why the network was able to quickly unite behind a single fork that fixed the inflation bug---because the bug made bitcoin diverge from the specification. everyone on the network had incentive to fix it.

the same was not true of the ethereum fork. that protocol was not what users opted into, so naturally some users did not support it.

You can check the main part of the DAO hard fork code here https://github.com/ethereum/go-ethereum/blob/master/consensus/misc/dao.go#L83 . Mutating the database values without valid signatures is a big no no if the protocol was working correctly.

theft on a massive scale---very dangerous precedent, no matter the underlying ethical considerations.

[gmaxwell]

Removing the 'overflow' transaction worked within the protocol and consensus systems.  Hashpower extended one chain rather than another, and eventually the network reorged.

If you were running old unfixed software you followed along just fine.

By comparison, in eth-- the rules of the idiot scam investment contract allowed someone to take the funds. Absolutely nothing malfunctioned in ethereum itself (for a change...), it worked precisely as it was supposed to. The webpages for this "investment" were abundantly clear in allcaps text: the programmed rules are binding and final.  Ethereum developers invested millions in the sketchy contract (and were in, fact, part of its operators as official advisers and key holders) and then when it didn't go their way they edited the ledger to restore the funds and forced users to upgrade, using the threat of withdrawing their support (which was significant, due to their massive premine).

Worse, when some users created a fork the ethereum corporation used an exploit on it to steal funds from the original attacker and then tried to dump them on the market ... but they got caught and ended up returning most of them.  Bitcoin wasn't made mutable in a way that it wasn't always mutable.

So by comparison:

Bitcoin itself malfunctioned in an obvious way where it couldn't continue since anyone being able to print billions of coins out of nothing is an obviously useless system.  Working *within* the consensus rules, using the fact that nodes follow the most-work-valid-chain the malfunctioning transaction was kicked out in a way where any transaction could have been kicked out.  Doing so created no winners or losers (Bitcoin simply couldn't continue under the broken rules)-- and absolutely no one complained about or disagreed with the change.  The developers/miners  that drove fixing it stood to gain nothing personally from the event, other than just keeping Bitcoin working at all.

Imagine that you reject the fix and want to keep running the original anyone-can-print-coins-out-of-nothing code.  You can do that. What chain are you on?  The current Bitcoin chain.

Even if you wanted to be an absolutist that we had to do what the code said-- the bug was actually triggering undefined behaviour in the C++ language.  It's not formally defined what happens when those signed integers overflowed.  Rejecting the transaction was as valid an action as accepting it, according to the C++ language.  Had it happened to be the case that a popular compiler saturated on signed overflow instead of wrapping or if popular ones crashed on signed overflow (some actually do, but didn't in this case), then what happened-- a chain without the txn gaining the most hashpower-- would have likely happened naturally without any human intervention at all, though it might have taken a while.

The "problem" in the case of Ethereum was that it worked exactly as designed and advertised. People with effective control didn't like the result, and edited the ledger to return funds to themselves. They manipulated the markets by demanding trading halts in secret (the logs of which have subsequently been leaked). When a competing chain was formed by users who disagreed with the ethics they attacked it technically and economically.  They personally benefited from this change, and in subsequent similar cases of flawed smart contracts -- including ones losing much more in terms of dollar value-- they declined to intervene (and opposed intervention) when their own funds weren't at risk.

I don't think it's remotely comparable:

Overriding the system (editing the ledger) vs Within the system (adding hashpower to a branch without the bad transaction)
Incompatible with prior software vs compatible with prior software (as a result of the above)
Clearly correct function (Ethereum) vs Objectively and indisputably incorrect function (Bitcoin)
Ethereum change just edited the ledger and made no fix to the system  vs Bitcoin change fixed the system without editing the ledger and the ledger fixed itself.
Personal profit vs No particular personal gains
Subsequently didn't aid in identical cases where eth admins had no losses vs no subsequent cases in Bitcoin (even though there were plenty of cases where bitcoin figures had losses)
Backroom dealing and pressure vs transparent communication
Acting to destroy peoples ability to disagree vs no one disagreeing

If you want to look at a similar event in Bitcoin's history-- go look at MTGox losing the customers funds.  No one (at least no one serious / high profile) even suggested editing the ledger to "fix" that-- even though many well known Bitcoin personalities would have theoretically stood to gain *enormously* if such a thing were done.

Why do people (including highly ranked Bitcointalk members) think of Ethereum Classic as the ‘real Ethereum’?

I haven't seen that.  Because Ethereum is massively premined (a windfall they're currently in the process of locking in by reducing the issuance again and then making it go exclusively to existing large holders), it's a centrally controlled system as was aptly demonstrated by the event in question.  It is whatever it's scamming owners want it to be, as you can see.

[BrewMaster]

the hypocrisy in ethereum is worst than any of its other flaws. the most centralized cryptocurrency has always been lying to people about everything from the premine, bugs, roll backs,... to nature of all future schemes like the 2.0 scheme.

so system, even the centralized ones, can function without rules. and rules have to be equal for everyone. that means when the subsequent smart contracts copied DAO and stole money in a similar fashion, they too should have been reversed. but none of them did simply because the centralized authority controlling ethereum's every aspect never lost any money in those smart contracts.

[Philipma1957cellphone]

One thing has been on my mind for a long time, and I wanted to talk about it here with the community.

So, let’s start from the beginning.

In August 2010, a hacker discovered a bug in Bitcoin’s codebase that allowed him to generate 184 billion bitcoins. These coins were sent to two different addresses that received 92 billion each in the famous block #74,638.

This would later become known as the overflow bug.

Information about this particular case can be found on the links below:
https://bitcointalk.org/index.php?topic=822.0
https://bitcointalk.org/index.php?topic=823.0
https://decrypt.co/39750/184-billion-bitcoin-anonymous-creator

Within 5 hours, Satoshi and the bitcoin developers rolled out a fix that patches the overflow bug incident.

Version 0.3.10 patches the block 74638 overflow bug.   http://bitcointalk.org/index.php?topic=823

The Linux version includes tcatm's 4-way SSE2 SHA-256 that makes generating faster on i5, i7 (with hyperthreading) and AMD CPU's.  Try the "-4way" switch to enable it and check if it's faster for you. 

Download from sourceforge:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.10/

SHA1 16645ec5fcdb35bc54bc7195309a1a81105242bb bitcoin-0.3.10-win32-setup.exe
SHA1 4f35ad7711a38fe8c880c6c9beab430824c426d3 bitcoin-0.3.10-win32.zip
SHA1 e3fda1ddb31b0d5c35156cacd80dee6ea6ae6423 bitcoin-0.3.10-linux.tar.gz
SHA1 b812ccff4881778b9090f7c0b0255bcba7b078ac bitcoin-0.3.10-macosx.zip

It is no longer necessary to delete blk*.dat.  The good block chain has overtaken the bad block chain, so you can just upgrade and it'll automatically reorg away the bad block chain.

A fork happened, and the blockchain was forked back to the state before block #74,638. Some blocks were invalidated, and all the transactions that were carried out were rolled back.   

Bitcoin survived and prospered into what we have today, and rightly so. Nobody seemed to have a problem because something that was supposed to be immutable (Bitcoin) became mutable for a bit.

Now to the second part of the story.

Six years later, in June 2016, we had the DAO hack. Over 3.5 million ether valued at $50 million were stolen from the DAO smart contract.
(https://www.coindesk.com/understanding-dao-hack-journalists) 

The days that followed created huge tensions within the Ethereum community that couldn’t be solved, so the blockchain had to fork and split into two. Those who believed in the immutability of Ethereum stayed with the original idea and called their new network Ethereum Classic. The majority supported the fork and stayed with Ethereum.

The reason the fork happened was to return the stolen funds, but the Ethereum Classic folks didn’t want any of that.


In my opinion, both the Bitcoin and Ethereum forks were carried out to benefit the communities.

1.   But why is it that one network is being criticised for not being immutable while the other isn’t?
2.   Why do people (including highly ranked Bitcointalk members) think of Ethereum Classic as the ‘real Ethereum’?
3.   If that is how it should be, shouldn’t we also have a ‘real Bitcoin’ where two addresses hold 92 billion coins each?
4.   Why is it not OK to perform a fork to refund stolen ether due to a buggy code, but it is OK to invalidate bitcoin blocks due to wrongly generated bitcoins? 
5.   Is bitcoin not attacked for the fork because the bug led to the creation of bitcoins much higher than the maximum supply?
6.   Would the opinions have been any different if a much lower number of coins were generated?

- Both forks fixed bugs in the codebase. One allowed to generate a huge number of bitcoins, the other to transfer big amounts of ether.

The difference is the BTC error destroyed the 21 million code set in stone rule. The rollback had to be done

The eth as I recall was more like an illegal transfer. Ie eth could still exist and the rollback did not have to be done. The coins could have stayed lost and code could have simply ended the chance to do it again.  Btw that rollback cost me two eth coins I have yet to recover. So I am not a fan of eth.

[acquafredda]

I think OP has already had his fair shares of great answers regarding the matter. Allow me to only point out that, being a highly ranked Bitcointalk member means nothing! There are very few Bitcointalk members, who also know the protocol and its rules very well and I believe none of them would ever compare what happened for the DAOHack to what happened because the overflow bug.
To sum up:
Bitcoin -> bug exploited->BTCspecs invalidated->fix
Ethereum->contract exploited (within the rules of the game)->massive whine by people who lost money->"fix"

[aliashraf]

The so-called DAO hack was not a hack, it was a direct consequence of what in computer science is discussed and formulized as decidability problem, actually it is one of the oldest fields of research in computational theory, and we have Turing in 1936 who showed that there is no algorithm that can prove an arbitrary program running on a Turing Machine will halt eventually for every given set of inputs (halting problem).
It is what makes Ethereum smart contracts and Turing Completeness of the machine to be seen as a very poor idea because letting Turing complete programs with recursion/loops to be launched on a decentralized financial network provides the basis for scamming people or putting them in accidental loss danger.

In DAO case, people were highly encouraged by Vitalik and the Foundation to put money in a smart contract that was sophisticated enough to be fed by special inputs from a smart person to fall in surprising branches of execution, sucking out all the funds. It had its roots in the most basic idea of Buterin for running a Turing Complete Language instead of the crafted Satoshi and bitcoin choice of an Automata scripting language which deliberately doesn't allow recursions and/or loops.

When DAO failed, the Foundation decided to write a few lines of code, taking back the lost coins. Besides being a total disgrace, the Eth fork was an attempt for denial of the actual flaw: The core idea of Ethereum.


P.S.
I may be wrong, but I feel it was after DAO and the Ethereum Foundation along with Buterin forking off from the legitimate chain while getting mainstream  that they started to realize that Ethereum is a property of them and invented/officialized the current model of governance that Ethereum is going through.  

[odolvlobo]

I first want to point out that everyone's answers (including mine) are primarily opinions because deciding which coin is the "real" coin is entirely a matter of opinion and politics. Generally, the "real" coin is arrived at by social dominance.

Is BTC or BCH (or BSV) the "real" Bitcoin? It depends on the opinion of the person you talk to. The genesis block is the same for all three and all three have had significant changes to the protocol. There are no technical reasons for claiming that one is the "real" Bitcoin and that the others are not. It is a personal preference.


1.   But why is it that one network is being criticised for not being immutable while the other isn’t?

Neither is 100% immutable. Because of the reasons for the forks, which might indicate the potential for further changes, some might consider the Ethereum chain to be less immutable.

2.   Why do people (including highly ranked Bitcointalk members) think of Ethereum Classic as the ‘real Ethereum’?

The Ethereum fork fixed a problem with a contract and not with Ethereum itself. The breach of trust is the real issue.

3.   If that is how it should be, shouldn’t we also have a ‘real Bitcoin’ where two addresses hold 92 billion coins each?

A branch without the fix would have failed, so it is irrelevant in the end. You could rationally say the the "real" Bitcoin had a fatal flaw and was replaced by a new better Bitcoin, but your opinion would be in the minority.
 
4.   Why is it not OK to perform a fork to refund stolen ether due to a buggy code, but it is OK to invalidate bitcoin blocks due to wrongly generated bitcoins?

The difference is that the Bitcoin fork fixed a problem with Bitcoin itself, and the Ethereum fork fixed a problem with a contract and not with Ethereum itself. Whether or not it is OK depends on the person. Also, note that invalidating blocks is a normal function in Bitcoin. All of the transactions (except for the broken transactions and the coinbase transactions) were still confirmed after the fork.

5.   Is bitcoin not attacked for the fork because the bug led to the creation of bitcoins much higher than the maximum supply?

If the bug wasn't fixed, Bitcoin would have failed.

6.   Would the opinions have been any different if a much lower number of coins were generated?

No. It wasn't a just single incident. It was a bug that anyone could exploit.

[gmaxwell]

I agree that Turing completeness is unnecessary (I believe this is indisputable, in fact) and an unwarranted liability but I don't really agree that it is to blame for the dao drama.

Undecidability means you cannot decide if an arbitrary program will halt (and, as a consequence, you usually can't make strong statements about what an undecidable arbitrary program will or won't do, since you can't tell if it will or won't halt before an arbritary step).  But even though a language is Turing complete an enormous portion of programs you might want to run on it are decidable, if you limit yourself to only engage with decidable programs then it could be absolutely proven that they will or won't take certain actions.   One can also use Bitcoin insecurely-- for example you could publish your private key on Bitcointalk-- and that doesn't make Bitcoin itself bad.  So, similarly, "arbitrary" usage of Bitcoin is insecure, but sane users don't use Bitcoin in arbitrary ways: they use it in safe ways.

Even if script allowed recursion and or loops, you could easily write script -- including ones that *used* the recursion and loops-- which could automatically be proven to meet whatever safety property you desired.  An arbitrarily selected program would not be provable, of course, but it's easy to write ones that are.  The absence of recursion/loops/etc, instead, make it a lot easier to reason about the safety and stability of the consensus rules and reduce the risk of scripts that crash nodes or use unreasonable amounts of resources.

For the Dao Debacle and many other horrifying eth failures, the real issue in my view is that these smart contracts are in fact cryptographic protocols but the whole frequently-hopping-scam-spectrum business model of ethereum (basically cooking up crooked financial schemes faster than people can get arrested for them or the public can learn to not get ripped off by them) basically depends on ignoring this unfortunate fact.  Make a smart contract is not really different than inventing a new block cipher, secure communications protocol (like TLS), or zero knowledge proof.  As cryptographic protocols we should recognize that they are ABSURDLY brittle, and that even when designed and reviewed by the worlds foremost experts they can easily contain utterly devastating flaws that leave them completely without security and these flaws can go a long time before they're detected and suddenly exploited.  As such, an extraordinary level of diligence is required when creating them, justifying things like formal methods (e.g. techniques to prove properties of computer programs).

And the eth software stack and ecosystem is not particularly well suited to the required sort of diligence-- worse, their smart contracting functionality is primarily promoted as being extremely accessible and suitable for even relatively inexperienced UI developers.  This is a toxic mix with predictable results.

But faulty smart contracts are extremely common in ethereum and were common before the dao drama, and yet they did not result in editing the ledger to steal funds from the technically-correct-but-surprising execution of the smart contract-- violating the "Unstoppable code" headline promise of the ethereum crowd sale.   So the flaws in the dao contract and the ethereum ecosystem aren't really relevant to the drama because they don't distinguish it from 100 other events.  What does distinguish it is *who* lost money and the incredible control they wield over the system because they premined the vast majorty of its coins and continue to control billions of dollars worth of them, and the lack of integrity and self control exhibited by those persons.

[pooya87]

I first want to point out that everyone's answers (including mine) are primarily opinions because deciding which coin is the "real" coin is entirely a matter of opinion and politics. Generally, the "real" coin is arrived at by social dominance.

It is like saying "it is a matter of opinion to say who the president of the country is". If the majority votes for candidate A then it doesn't matter if someone's opinion is for candidate B, president would be candidate A.
In bitcoin, and any decentralized cryptocurrency, the majority is 95%+ of the network, and when they vote that a certain chain is the real bitcoin then that IS the "real bitcoin".

here are no technical reasons for claiming that one is the "real" Bitcoin and that the others are not.

I just gave you one. It is also how bitcoin was designed.

The Ethereum fork fixed a problem with a contract and not with Ethereum itself.

That's the problem though, they didn't fix any problem, they just erased the issue. The real problem still exists and can happen, in fact it has happened again a couple of times already!

You could rationally say the the "real" Bitcoin had a fatal flaw and was replaced by a new better Bitcoin

When you say "Bitcoin", it is a protocol not a client. The protocol dictates that a block (at that time) could create no more than 50 new coins. When it creates more, it is not a flaw in Bitcoin, it is a flaw in the client.
A similar flaw in the "client" happened again back in 2018 which again has nothing to do with Bitcoin protocol but the implementation of the protocol.

[aliashraf]

I agree that Turing completeness is unnecessary (I believe this is indisputable, in fact) and an unwarranted liability but I don't really agree that it is to blame for the dao drama.

Undecidability means you cannot decide if an arbitrary program will halt (and, as a consequence, you usually can't make strong statements about what an undecidable arbitrary program will or won't do, since you can't tell if it will or won't halt before an arbritary step).  

I'm afraid, you are underestimating the problem. Turing completeness is not just an unnecessary feature, it is a wrong design principle for public consensus based decentralized systems. DAO incident was a direct result of such a design flaw.

But even though a language is Turing complete an enormous portion of programs you might want to run on it are decidable, if you limit yourself to only engage with decidable programs then it could be absolutely proven that they will or won't take certain actions.   One can also use Bitcoin insecurely-- for example you could publish your private key on Bitcointalk-- and that doesn't make Bitcoin itself bad.  So, similarly, "arbitrary" usage of Bitcoin is insecure, but sane users don't use Bitcoin in arbitrary ways: they use it in safe ways.

When Turing says arbitrary he is referring to a mathematical concept it doesn't imply a "bad written" code or a random sequence of instructions chosen by a careless user, the theorem simply says that there is no algorithm to prove any other program with specified inputs as being able to reach a halt point or not reaching a specified point of execution.

Bitcoin machine is not Turing complete because of a design principle decided by Satoshi to keep the network (not just a single user) safe against malicious scripts. It is a trade-off, you are right, but a reasonable and well thought one for a system that is supposed to maintain its stability for decades and is not supposed to have a "Foundation" that is able to clean the mess now and then.

Even if script allowed recursion and or loops, you could easily write script -- including ones that *used* the recursion and loops-- which could automatically be proven to meet whatever safety property you desired.  An arbitrarily selected program would not be provable, of course, but it's easy to write ones that are.  The absence of recursion/loops/etc, instead, make it a lot easier to reason about the safety and stability of the consensus rules and reduce the risk of scripts that crash nodes or use unreasonable amounts of resources.

Unfortunately, according to Turing, there is and there will be no automatic way to prove anything when it comes to recursions and loops, remember that inputs are to be chosen arbitrary.

But faulty smart contracts are extremely common in ethereum and were common before the dao drama, and yet they did not result in editing the ledger to steal funds from the technically-correct-but-surprising execution of the smart contract-- violating the "Unstoppable code" headline promise of the ethereum crowd sale.   So the flaws in the dao contract and the ethereum ecosystem aren't really relevant to the drama because they don't distinguish it from 100 other events.  What does distinguish it is *who* lost money and the incredible control they wield over the system because they premined the vast majorty of its coins and continue to control billions of dollars worth of them, and the lack of integrity and self control exhibited by those persons.

You are absolutely right here, yet there is a complementary and ironic fact:
In the case of Parity wallet bug event, people lost a comparable amount of money, but the Foundation didn't fix it even though there have been several hard forks after the event, obviously they had no coins put in that wallet.  
A close examination of the Parity bug event reveals a very important fact: It was almost the only big failure in Ethereum that deserved a fix! Why? Because it was not a problem with the logic of the smart contract involved, it was an implementation specific bug (using a public library, ...) pretty compatible to the 2010 overflow bug in bitcoin.

[Pmalek]

@oryhp
Excellent points oryhp. I was also of the opinion that the reason why Bitcoin wasn't and isn't being condemned the fact that the protocol didn't function as it should have. Thanks for confirming and clarifying in great detail.

@oryhp gave an excellent reply I just want to add that the terminology here is wrong. Discarding invalid blocks is not called "roll back", it is simply discarding invalid blocks. And those blocks were NOT invalidated, they were already invalid.

OK, fair point. But what happened with 'legit' transactions mined in the blocks that followed immediately after block #74,638?
If you and I made a trade of some sorts and I sent you 1 BTC as payment in block 74,639, after the bug was patched wasn't this money returned to the original address. I now have the goods you sent + the 1 BTC I paid you.

Subsequently didn't aid in identical cases where eth admins had no losses vs no subsequent cases in Bitcoin (even though there were plenty of cases where bitcoin figures had losses)
...
If you want to look at a similar event in Bitcoin's history-- go look at MTGox losing the customers funds.  No one (at least no one serious / high profile) even suggested editing the ledger to "fix" that-- even though many well known Bitcoin personalities would have theoretically stood to gain *enormously* if such a thing were done.

Excellent comparison, thank you!

...none of them would ever compare what happened for the DAOHack to what happened because the overflow bug.

It was clear to me from the start that the two cases are not identical, but I had to compare two cases of human intervention on a network, no matter what the reasons behind those interventions were.

All of the transactions (except for the broken transactions and the coinbase transactions) were still confirmed after the fork.

I wasn't aware of that. I though all the transactions in the blocks that were carried out from the problematic block until the patch was released also became invalid. They stayed valid?

If the bug wasn't fixed, Bitcoin would have failed.

If someone discovers a bug that allows him to empty certain addresses, that too would be a bad signal for Bitcoin. Should that also be fixed or is it just bad luck for those bitcoin holders?   

[pooya87]

OK, fair point. But what happened with 'legit' transactions mined in the blocks that followed immediately after block #74,638?

https://bitcointalk.org/index.php?topic=823.msg9623#msg9623

If you and I made a trade of some sorts and I sent you 1 BTC as payment in block 74,639, after the bug was patched wasn't this money returned to the original address. I now have the goods you sent + the 1 BTC I paid you.

In any case when going into a ~one year old currency that is first of its kind and running the 3^rd beta version of a software, one should expect some risks.
This is why I always tell people who complain about "early adopters" that they took a much bigger risk than them and their reward is proportional to that risk.

[Karartma1]

OK, fair point. But what happened with 'legit' transactions mined in the blocks that followed immediately after block #74,638?

https://bitcointalk.org/index.php?topic=823.msg9623#msg9623

If you and I made a trade of some sorts and I sent you 1 BTC as payment in block 74,639, after the bug was patched wasn't this money returned to the original address. I now have the goods you sent + the 1 BTC I paid you.

In any case when going into a ~one year old currency that is first of its kind and running the 3^rd beta version of a software, one should expect some risks.
This is why I always tell people who complain about "early adopters" that they took a much bigger risk than them and their reward is proportional to that risk.

I agree, there was nothing like bitcoin back then and everyone knew this was an early experiment. The most important thing to have in mind when comparing the two incidents is that the overflow bug went against the bitcoin protocol and specifications; the ethereum fiasco was a way to put a patch up a mess!

[acquafredda]

4.   Why is it not OK to perform a fork to refund stolen ether due to a buggy code, but it is OK to invalidate bitcoin blocks due to wrongly generated bitcoins? 

Because the problem lies within smart contact, not protocol itself. But even Ethereum community today knows it's not OK to do that since there are big amount funds locked/stolen because buggy smart contract after DAO Hack, but so far there's no serious attempt to refund those funds.

In fact that is very important too. Ethereum was doing, as a protocol, while the same cannot be said for poorly developed "smart contracts".

Once the crowdsale was over, there was much discussion of first addressing the vulnerabilities before starting to fund proposals. In particular, Stephan Tual, one of The DAO’s creators, announced on 12th June that a “recursive call bug” had been found in the software but that “no DAO funds [were] at risk”.  An unknown attacker began using this approach to start draining The DAO of ether collected from the sale of its tokens.
By Saturday, 18th June, the attacker managed to drain more than 3.6m ether into a “child DAO” that has the same structure as The DAO. The price of ether dropped from over $20 to under $13.

That was the issue, really. Nothing else. Those to blame were known for such a poor risk management.

[odolvlobo]

I first want to point out that everyone's answers (including mine) are primarily opinions because deciding which coin is the "real" coin is entirely a matter of opinion and politics. Generally, the "real" coin is arrived at by social dominance.

It is like saying "it is a matter of opinion to say who the president of the country is". If the majority votes for candidate A then it doesn't matter if someone's opinion is for candidate B, president would be candidate A.
In bitcoin, and any decentralized cryptocurrency, the majority is 95%+ of the network, and when they vote that a certain chain is the real bitcoin then that IS the "real bitcoin".

There are no technical reasons for claiming that one is the "real" Bitcoin and that the others are not.

I just gave you one. It is also how bitcoin was designed.

Show me the vote. There was no voting. Regardless, there is no logic or technical justification for the "real" bitcoin to be decided by a vote. There is no part of any design that states that the "real" bitcoin is the one that gets the majority of votes. The designation is entirely subjective. It is your opinion that the "real" bitcoin is the one that most people consider to be the "real" bitcoin. I happen to agree, but only because it is convenient, and it really doesn't matter.

You could rationally say the the "real" Bitcoin had a fatal flaw and was replaced by a new better Bitcoin

When you say "Bitcoin", it is a protocol not a client. The protocol dictates that a block (at that time) could create no more than 50 new coins. When it creates more, it is not a flaw in Bitcoin, it is a flaw in the client.
A similar flaw in the "client" happened again back in 2018 which again has nothing to do with Bitcoin protocol but the implementation of the protocol.

The protocol is defined by the code. That is why there is no Bitcoin protocol specification. If there is a bug in the code, it is part of the protocol. You might not agree with that in principal, but you would be in the minority. I don't like it, but I think it will be a long time before a specification determines the implementation.

[gmaxwell]

When Turing says arbitrary he is referring to a mathematical concept it doesn't imply a "bad written" code or a random sequence of instructions chosen by a careless user, the theorem simply says that there is no algorithm to prove any other program with specified inputs as being able to reach a halt point or not reaching a specified point of execution.

...

Unfortunately, according to Turing, there is and there will be no automatic way to prove anything when it comes to recursions and loops, remember that inputs are to be chosen arbitrary.

Ah, that isn't quite correct-- unless I misunderstand you and we're just violently agreeing.  You can very easily make a program to prove other programs will halt. But it will have to sometimes output "I dunno".  On some programs it will output "Halts", others "Runs forever"-- but if it's deciding a turing complete language it will sometimes have to yield an "I dunno".

The ambiguity of English with respect to the meaning of "any" is annoying which is why the word arbitrary is important.  You can make a decider that decides if some programs will halt, but you cannot make a decider that will be able to decide all arbitrary programs without the possibility of returning that it can't tell. But users of smart contracts don't use arbitrary programs, they use specific ones and can restrict themselves to ones that can be decided.

An easy way to see this is so is to imagine that it simply looks for any loops or recursion and returns I dunno if they're *used*, in that example the language is Turing complete, but it checks if you use that ability.  Obviously that is a little limiting, so it can then allow them but only when it can prove how many times they'll execute at most.  So for example, if you have a program that does a for(int i=0;i<min(5,max(1,input));i++) and contains no other writes to i, then a program can prove the the loop will run only 1-5 times and thus will halt.

This kind of variable range analysis is something any moderately complex compiler already does already (e.g. it's needed for things like loop unrolling or to prove some code is dead so it can be eliminated).

A concrete example of this is the ebpf system in linux that lets you inject tiny programs into the kernel.  The ebpf language allows arbitrary jumps, but at load time the kernel performs an analysis and will not let you load an ebpf program that it cant prove will halt (in fact, there is even support now for loops like the one I describe above).  Sometimes you will write an eBPF program that absolutely will halt, but the prover in the kernel is just too stupid to reason it out and you'll have to use a different program.  Data-dependant-but-bounded loops are an example prior to the change I linked,  and you could usually work around that limit by always looping the maximum number of times and including conditions to make some of those loops do nothing, depending on the data.

Another really dumb example would be if the prover simply ran the program on all possible inputs, and if it was able to exhaust the input space with fewer than a million operations performed, it would return halt, if it detects (in fewer than a million operations performed) that the program reached a state that it had been in before *exactly* then it returns "runs forever", and if it runs into its million operation limit it returns "I dunno".   This is a dumb and inefficient example.  But it gives an intuition about how even though the problem of deciding is intractable by adding the possibility of returning "I dunno" it becomes tractable.

There is a whole field of formal validation which is all about reasoning about programs, including ones written for Turing complete languages, and proving their properties (including that they will halt).  All turing's thesis means is that it will always be possible to create programs that these systems cannot reason about, but that isn't a problem for a prospective user because they get to pick the programs will or won't use.

In any case, this is just pointing out that *users* can still safely reason about the programs they choose to use when they use a turing complete system, because unlike the turing decider program they don't have to work on all programs, just a subset of them and they can refuse to use any their tools can't analyize.

to keep the network (not just a single user) safe against malicious scripts

That's true (though it's overkill, one can protect the network with less potent means -- like how the linux kernel protects itself from rogue eBPF programs), but it's not relevant to the discussion here.  The DAO's faulty script wasn't a question of network protection, it was a question of users failing to protect themselves.  It only became a network issue because the corrupt administrators of ethereum had invested in the dao, weren't willing to take a loss in the name of principles, and had the level of control required to pull it off.

It is a trade-off

I actually don't think it's a actually trade-off: I believe that every program usefully expressed for a blockchain can be expressed without turing completeness: This is because validating the result of any NP language can be done in P time.   Blockchains don't need to actually compute anything (and ought not to): they can verify the computation performed by some user/host external to the consensus... and that's obviously what you want to do because operation inside consensus is absurdly expensive.

You are absolutely right here, yet there is a complementary and ironic fact:
In the case of Parity wallet bug event, people lost a comparable amount of money, but the Foundation didn't fix it even though there have been several hard forks after the event, obviously they had no coins put in that wallet.  
A close examination of the Parity bug event reveals a very important fact: It was almost the only big failure in Ethereum that deserved a fix! Why? Because it was not a problem with the logic of the smart contract involved, it was an implementation specific bug (using a public library, ...) pretty compatible to the 2010 overflow bug in bitcoin.

Eh. It was an implementation bug in the smart contract, not ethereum itself-- pretty similar to the DAO.  Perhaps it's better to note that fixing it wouldn't be stealing from anyone: the funds are just frozen.  Vs in the case of the DAO taking the funds back didn't just violate the smart contract, it unambiguously violated the human-language legal contract on the DAO website because it was all-caps unambiguous that even if the smart contract did something nuts, it was what governed the agreement.

If someone discovers a bug that allows him to empty certain addresses, that too would be a bad signal for Bitcoin. Should that also be fixed or is it just bad luck for those bitcoin holders?  

Your question is underspecified. A bug in what?  In a smart contract their wallet uses?  That has happened before, tough "luck" for them.  There was even a case that people lost money due to a miner in bitcoin core, and it was just tough luck for them.

An example of this is that MTGox sent thousands of Bitcoin to an improperly encoded scriptpubkey, tough luck for them (and their customers-- which, incidentally included myself and may other long time well know bitcoiners).

The integrity of the system is almost its only reason to exist, and it's not something to be trifled with just because some users messed up.

If instead you mean some consensus bug that allowed, e.g. validation to be bypassed due to a flaw in Bitcoin itself. That's sort of issue can be softforked out -- not accepting the bogus spends -- without breaking the consensus.  And has been:  Originally a spending scriptSig could just toss in a OP_TRUE OP_RETURN and the spend would be accepted before the payer specified conditions were ever even evaluated.  Satoshi deployed a change that wouldn't admit transactions that used OP_RETURN at all (it would have been sufficient to deny it in only scriptSigs, but at the time the interpreter worked by concatenating the scriptpubkey onto the scriptsig so it wasn't simple to make this distinction).  This didn't disrupt consensus because nodes already have the unavoidable ability to decline to include transactions that are otherwise valid... and once more than half the hashpower was running this rule it could be enforced without any potential for a lasting consensus split.

A generation ago, multi-user time-sharing computer systems had a similar problem. Before strong encryption, users had to rely on password protection to secure their files, placing trust in the system administrator to keep their information private. Privacy could always be overridden by the admin based on his judgment call weighing the principle of privacy against other concerns, or at the behest of his superiors. Then strong encryption became available to the masses, and trust was no longer required. Data could be secured in a way that was physically impossible for others to access, no matter for what reason, no matter how good the excuse, no matter what.

(emphasis mine)

Ethereum blabbered on about "unstoppable code" but at the end of the day for ethereum it's just marketing blather  For whatever its other faults, Bitcoin exists for a reason higher than just making money for people... having principles means that you sometimes have to bite the bullet and take on an uncomfortable cost, because to fail to do so would moot the endeavour.

[aliashraf]

@gmaxwell,
It is not appropriate for either of us to debate every single point. Briefly speaking:

1- You think implementing Ethereum VM as a Turing Complete machine was not a design flaw per se, and it is up to users to commit to good scripts, the ones that are decidable.

2-Starting from there, you conclude that DAO incident was about a malicious script and a smart person who fed the script with special inputs, exploiting the vulnerability of the script and seizing the funds locked there.

3- Finally, as of Parity wallet bug you suggest that it was not essentially different with DAO case because you suppose both of them were instances of a failed smart contract.

I will trace bottom-up, if you don't mind:

3,2- Being users' responsibility or not, DAO failed because of its dark side, hidden in the twilight of undecidability, it was not an implementation problem or a bug unlike DAO the Parity wallet issue was due to a stupid programming/integration flaw, i.e. using a public library call not owned by the contract. It could happen with or without Turing completeness, just any other programming bug, just like bitcoin 2010 overflow bug, radically different with DAO.

1- I maintain that implementing Turing complete scripting languages in cryptocurrency is a weak idea because it exposes people to great risks when it comes to serious/sophisticated applications while for simple use-cases there is a good chance to be implemented on an Automata machine with strict predictability.