4 ms·

"altcoin" is a highly misleading term for that. That term already means "a cryptocurrency unrelated to bitcoin", typically having a different genesis block, sub

by TheDong 11y ago

"altcoin" is a highly misleading term for that. That term already means "a cryptocurrency unrelated to bitcoin", typically having a different genesis block, subsequently an entirely different chain, and often further differences. We already have a term exactly for what you're talking about: a hard-fork (or just a fork if you like). On either side of the fork is bitcoin, not the "original" bitcoin and an "altcoin". You're also incorrect in other ways. In the case of most forks, you fork via voting by "x% of the last 1000 blocks were mined by this implementation". Because of that, if everyone except the current miners use the alternate implementation, the new "fork" will never activate. That's because forks are not altcoins, but typically run on the same exact chain, behave compatibly with each other (prior to activation), and wait for consensus in mined blocks (to activate). That method of voting does mean that only miners get a vote. It's not because they validate all blocks, but rather because mining a block is the same as voting in basically all fork-consensus-algorithms so far.

makomk 11y ago
You're conflating two fundamentally different kinds of forks. The ones activated through voting were soft forks, where old nodes still accepted all blocks mined by the new ones, and the voting was to ensure that enough miners would enforce the new rules to overtake any chains created by the old nodes and bring everyone back onto the same chain - that is, it was necessary to ensure there wasn't a permanent fork. This simply doesn't apply to hard forks because by definition, the old nodes will not accept the newer fork no matter how long it grows. Calling it "voting" is kind of a misnomer - it's a purely technical measure to make sure soft forks don't break Bitcoin when they activate.
- TheDong 11y ago
  "voting" is a technical concept used in many distributed systems; even if it's a purely technical concept that term is correct. Voting also applies in hard-forks. Case-in-point, XT/classic both had activation thresholds and voting. Splitting the chain is not really useful unless you have a large majority with you for both technical and non-technical reasons, and so you vote. Soft-forks and hard-forks aren't so different in the happy-case. They both extend the same original chain, they both have concerns about two competing chains existing and wish to avoid that, they both change the validation layer in some way (though to lesser and greater extents).
vertex-four 11y ago
> On either side of the fork is bitcoin, not the "original" bitcoin and an "altcoin". The point is that on one side you have the original protocol in use, and on the other side you have a different protocol in use. Both of them are called Bitcoin and use the same database up to the point of the fork, but they're not the same protocol in much the same way that Dogecoin is not the same protocol as Bitcoin - someone who attempts to use the pre-fork protocol will not be able to achieve consensus with someone attempting to use the post-fork protocol. > In the case of most forks, you fork via voting by "x% of the last 1000 blocks were mined by this implementation". That is not the only way to implement a fork. As I say, you can fork the chain simply by convincing enough users to use your fork - there's no hard requirement for any miner-level voting to be done at all.
- TheDong 11y ago
  The bitcoin protocol is doing whatever the most popular bitcoin client does. After a fork it's the same. > but they're not the same protocol in much the same way that Dogecoin is not the same protocol as Bitcoin What you're arguing is essentially that "EMCA6 is not javascript because it supports features the previous javascript didn't, much the same as ruby does". Bitcoin is a cryptocurrency. They're the same cryptocurrency both before and after the fork. Dogecoin is not. Can you see how that term is not a good term when we have a better one? Also "achieve consensus" there is absolutely incorrect. The correct term is "will have to update their software, else they will be incompatible". Software updates are normal, and we don't demand that each program rename itself every time it updates. > That is not the only way to implement a fork That's the only way anyone's trying to fork though. Yes, gavin said he'd just do a hard-cut over, but he didn't and it'd be a bad idea. Forking the chain is only useful if the economic majority and miners come along, else your chain will be less secure and less useful (also, double spending problems etc).
  - vertex-four 11y ago
    > EMCA6 is not javascript because it supports features the previous javascript didn't, much the same as ruby does Or, rather, ECMAScript 6 is not ECMAScript 5 because you can write code in the former that doesn't work in the latter, and probably vice versa on edge cases. They are separate languages. If you continue writing in ECMAScript 5, you're missing out on all the nice ECMAScript 6 libraries. But with Bitcoin it's even worse - if you continue using pre-fork Bitcoin, you cannot reach consensus and thus transact with people using post-fork Bitcoin. They're not precisely the same protocol, by definition - they bare the same name but they're not the same protocol, they are different protocols and for the fork to win, the first protocol dies. The name is irrelevant to this. Similarly, HTTP 2.0 isn't the same as HTTP 1.1, and claiming one is equivalent to the other is nonsense, even if they bare the same name. I'd also argue that if the amount of hash power put into the network can be derived from the value of the network (trivially provable), the result of the economic majority choosing to adhere to different rules is that either the miners will follow or new miners will pop up quickly as there's a demand for them.

by TheDong 11y ago

makomk 11y ago

You're conflating two fundamentally different kinds of forks. The ones activated through voting were soft forks, where old nodes still accepted all blocks mined by the new ones, and the voting was to ensure that enough miners would enforce the new rules to overtake any chains created by the old nodes and bring everyone back onto the same chain - that is, it was necessary to ensure there wasn't a permanent fork. This simply doesn't apply to hard forks because by definition, the old nodes will not accept the newer fork no matter how long it grows. Calling it "voting" is kind of a misnomer - it's a purely technical measure to make sure soft forks don't break Bitcoin when they activate.

TheDong 11y ago
"voting" is a technical concept used in many distributed systems; even if it's a purely technical concept that term is correct. Voting also applies in hard-forks. Case-in-point, XT/classic both had activation thresholds and voting. Splitting the chain is not really useful unless you have a large majority with you for both technical and non-technical reasons, and so you vote. Soft-forks and hard-forks aren't so different in the happy-case. They both extend the same original chain, they both have concerns about two competing chains existing and wish to avoid that, they both change the validation layer in some way (though to lesser and greater extents).

vertex-four 11y ago

> On either side of the fork is bitcoin, not the "original" bitcoin and an "altcoin". The point is that on one side you have the original protocol in use, and on the other side you have a different protocol in use. Both of them are called Bitcoin and use the same database up to the point of the fork, but they're not the same protocol in much the same way that Dogecoin is not the same protocol as Bitcoin - someone who attempts to use the pre-fork protocol will not be able to achieve consensus with someone attempting to use the post-fork protocol. > In the case of most forks, you fork via voting by "x% of the last 1000 blocks were mined by this implementation". That is not the only way to implement a fork. As I say, you can fork the chain simply by convincing enough users to use your fork - there's no hard requirement for any miner-level voting to be done at all.

TheDong 11y ago
The bitcoin protocol is doing whatever the most popular bitcoin client does. After a fork it's the same. > but they're not the same protocol in much the same way that Dogecoin is not the same protocol as Bitcoin What you're arguing is essentially that "EMCA6 is not javascript because it supports features the previous javascript didn't, much the same as ruby does". Bitcoin is a cryptocurrency. They're the same cryptocurrency both before and after the fork. Dogecoin is not. Can you see how that term is not a good term when we have a better one? Also "achieve consensus" there is absolutely incorrect. The correct term is "will have to update their software, else they will be incompatible". Software updates are normal, and we don't demand that each program rename itself every time it updates. > That is not the only way to implement a fork That's the only way anyone's trying to fork though. Yes, gavin said he'd just do a hard-cut over, but he didn't and it'd be a bad idea. Forking the chain is only useful if the economic majority and miners come along, else your chain will be less secure and less useful (also, double spending problems etc).
- vertex-four 11y ago
  > EMCA6 is not javascript because it supports features the previous javascript didn't, much the same as ruby does Or, rather, ECMAScript 6 is not ECMAScript 5 because you can write code in the former that doesn't work in the latter, and probably vice versa on edge cases. They are separate languages. If you continue writing in ECMAScript 5, you're missing out on all the nice ECMAScript 6 libraries. But with Bitcoin it's even worse - if you continue using pre-fork Bitcoin, you cannot reach consensus and thus transact with people using post-fork Bitcoin. They're not precisely the same protocol, by definition - they bare the same name but they're not the same protocol, they are different protocols and for the fork to win, the first protocol dies. The name is irrelevant to this. Similarly, HTTP 2.0 isn't the same as HTTP 1.1, and claiming one is equivalent to the other is nonsense, even if they bare the same name. I'd also argue that if the amount of hash power put into the network can be derived from the value of the network (trivially provable), the result of the economic majority choosing to adhere to different rules is that either the miners will follow or new miners will pop up quickly as there's a demand for them.