[CydeWeys]

This looks really bad from the perspective of trusting the currency to actually retain its value. What if you end up on the wrong fork, and that thousands of dollars in Ethereum you accepted to send out physical goods ends up being worthless?

What's the point in saving the DAO if it kills the whole purpose behind the currency?

[Bromskloss]

Won't you own Ether, and everything else, on both branches in the event of a fork?

[mcherm]

Ether that you own (not related to the DAO) before the fork happens would be unaffected by the fork. But after the fork, suppose you accept payment for something. You can accept payment in cash, Bitcoin, Ether-on-left-side-of-fork, or Ether-on-right-side-of-fork. I suppose you could also insist on getting paid in BOTH "Ether-on-left-side-of-fork" and ALSO in "Ether-on-right-side-of-fork", but that starts to get really complicated.

[CydeWeys]

In practice I think I'd sooner switch back to a non-forked cryptocurrency than try to deal with running multiple forks and ensuring that I'm getting paid on all of them. That sounds like a right huge mess to deal with, as you point out.

[CydeWeys]

Not if the transactions happen after the fork, and on the "wrong" one. If you're purely using Ethereum as a store of value, and already have all your funds put into it, then this won't affect you, sure. But if you're actually trying to use it as a currency like intended, then you're screwed.

Money isn't very useful if you can't transact it at all for fear that new transactions won't be any good.

[api]

That's not confusing at all.

[Bromskloss]

What do you mean?

[CydeWeys]

I assume he's being facetious, because it is confusing. Especially imagine someone requesting payment in Ethereum, and you think you've paid, and then they come back and say that you paid with funds on the wrong chain, and to re-send the funds on a different chain. There isn't a client I'm aware of that supports simultaneous operation on multiple chains. It gets very hard to deal with very quickly.

[Bromskloss]

Right, but that's simply how blockchains work.

[ikeboy]

As I understand it they only activate the fork if enough miners vote for it. If >50% of hashpower doesn't fork, then nobody forks. If >50% of hashpower forks, then that's known ahead of time since the vote was carried out in public by that same hashpower.

[Zagitta]

That's how the softfork worked before it got scrapped. A hardfork literally splits the network in in two, it's basically like creating a new coin shares the previous history.

[ikeboy]

How does the fact that it was a hardfork invalidate either of the statements above? It's known ahead of time, and if not enough people adopt it then it doesn't get activated at all.

[Zagitta]

The way it invalidates the above statement is that there's no code that decides whether the fork happens beside what flags the nodes are launched with. At the specific block number the nodes that accept the fork will only validate the hardfork blocks as correct while the nodes that don't support the fork will reject these blocks. Thus two chains will co-exist for an unknown amount of time, not just one or the other.

To some extend what you're saying is true though as it's very unlikely that both chains will remain active/retain it's value and therefore miners on the losing chain will likely move to the winning chain very fast to avoid losses incurred from the cost of power.

[ikeboy]

>there's no code that decides whether the fork happens beside what flags the nodes are launched with

That's not what you said above. You claimed that the mere fact that it's a hardfork means that you cannot implement anything to only activate if there's a majority. But it's extremely simple to do so. Just check whether a supermajority or a plain majority of recent blocks have signalled support for the hard fork, and only produce hardfork blocks if they have.

Quoting from the blog post https://blog.ethereum.org/2016/07/15/to-fork-or-not-to-fork/

>The community tool carbonvote will be used to set the default fork option for Geth. At block number 1894000 the votes will be tallied, and the outcome will determine whether the default is set to fork or not to fork. Then merging the DAO fork PRs will proceed, followed shortly by a release for both Geth and Mist.

So they're only going to merge the hardfork code if they already have the votes.

[Zagitta]

i did not mean to imply that a hardfork can't be implemented in that fashion, I should indeed have written "the hardfork" instead of "a hardfork" as that's the way this specific hardfork has been implemented, I appologies English is not my native language.

My understanding of that blog post is only what the default value of supporting or not supporting is meaning the hardfork code will be merged in either case and that it's only whether it's active by default that's changed depending on the vote.

Not that it really matters anymore as block number 1894000 has already passed and the code merged with hardfork support enabled by default.

[fragsworth]

This is also an existing problem in every cryptocurrency. Just because bitcoin hasn't done any controversial forks yet doesn't mean it will never happen.

[LoSboccacc]

There has been a push for a longer blockchain for quite a long time now and when the mines dry up it may become a very hot potato