Franky, you're spreading a lot of misinformation. I won't go so far as to call it
disinformation, but I'm not sure that your intentions here are honorable. I can't keep responding to you because every time I address your points, you repeat the same falsities that I've already shown to be false.
No, I am not. This has nothing to do with controversy. A hard fork, by definition, entails creating a new network that is incompatible with the old one. The intention of a hard fork is for users of the old network to migrate to the forked network. There is no propaganda in that, whatsoever.
Supporting Core's conservative method of rigorous analysis and testing, or their overall roadmap, or simply supporting an implementation that retains Bitcoin's consensus rules, is not anything you can blame Core for.
1. hardfork code has been publicly available since last year, meaning core is not conservative. because they ignore code available for over a year to quickly push something only finalised a few weeks ago..
Segwit has been worked on since late last year. It's been rigorously tested for many months. Simply stating that "hard fork code has been publicly available since last year" is meaningless. That doesn't suggest that the hard fork code is sensible, optimal nor rigorously tested. Rather, peer review and testing has been minimal.
2. core is not retaining consensus rules.. old nodes cant validate segwit, so old nodes are not part of the consensus. they are just blindly confused into not caring what the data is by using the flag that tells them to ignore it.
Please point to the consensus rules being broken by Segwit. You can't, because there are none. This is why Segwit is backward compatible.
Old nodes certainly can validate Segwit transactions against the consensus rules. And they will. You seem disturbed by the idea of
forward compatibility, but it's really quite elegant and appropriate. See Satoshi's thoughts on forward compatible soft forks:
The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime. Because of that, I wanted to design it to support every possible transaction type I could think of. The problem was, each thing required special support code and data fields whether it was used or not, and only covered one special case at a time. It would have been an explosion of special cases. The solution was script, which generalizes the problem so transacting parties can describe their transaction as a predicate that the node network evaluates. The nodes only need to understand the transaction to the extent of evaluating whether the sender's conditions are met.
The script is actually a predicate. It's just an equation that evaluates to true or false. Predicate is a long and unfamiliar word so I called it script.
The receiver of a payment does a template match on the script. Currently, receivers only accept two templates: direct payment and bitcoin address. Future versions can add templates for more transaction types and nodes running that version or higher will be able to receive them. All versions of nodes in the network can verify and process any new transactions into blocks, even though they may not know how to read them.
The design supports a tremendous variety of possible transaction types that I designed years ago. Escrow transactions, bonded contracts, third party arbitration, multi-party signature, etc. If Bitcoin catches on in a big way, these are things we'll want to explore in the future, but they all had to be designed at the beginning to make sure they would be possible later.
I don't believe a second, compatible implementation of Bitcoin will ever be a good idea. So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network. The MIT license is compatible with all other licenses and commercial uses, so there is no need to rewrite it from a licensing standpoint.
3. core is not retaining consensus rules.. 4mb blockweight is a total different rule than maxblocksize.. but again by disabling consensus(consent) they are changing rules without needing consent.
Again: Please point to the consensus rules being broken by Segwit. You can't, because there are none. Maxblocksize is a consensus rule. It is not broken by Segwit. Segregating the witness data doesn't affect validity. It's really quite a clever way to optimize transactions size while permitting features which require non-malleability.
4. the road map belongs to core, the segwit code is a core feature and core are avoiding accepting hard fork code so much they are throwing devs out of the core group
Anyone is free to contribute to Core. Anyone is also free to develop other clients. Being a small, vocal minority should not enable someone to steamroll the rest of the project contributors into merging code they disagree with. You have no authority to say what Core should or should not do. You are free to contribute to other projects. Go ahead.
You can blame the lack of convincing arguments by fork proponents for the lack of support to fork. You could also probably blame Ethereum, which has likely scared much of the community away from the risks of hard forks.
the REKT and fake doomsdays stories to sway people started way before ethereum
Indeed, anti-fork sentiment existed long before the Ethereum network split. But the failed hard fork scared a lot of people into recognizing that Core's position has been reasonable and thoughtful, while the Ethereum Foundation has clearly been reckless and disdainful towards their userbase and custodians.
"Consensual [hard] fork" is a strange term. Consent flows from users opting into a network. Anyone is free to opt out of the Bitcoin network and consent to a new hard fork. But that doesn't imply at all that all users of the Bitcoin network consent to a hard fork. Knowing that every user consents is not possible in any way, shape or form -- and even if it were, we could only know after the fork had occurred, after which users actually migrate and affirmatively consent to the hard fork's new rules.
see there you go again "opt out of bitcoin network".. more subtly propaganda that if its not the core way then its not bitcoin..
yet core are changing the rules without needing users consent for the new direction core want to go.
No, it's not propaganda at all. You either fundamentally misunderstand what a hard fork entails, or you yourself are attempting to spread lies to further your agenda.
Are you suggesting that the Bitcoin network doesn't exist? Because if the Bitcoin network exists, a hard fork of Bitcoin's consensus protocol will create an additional network that is incompatible with Bitcoin. It's curious that you don't deny this, yet you continue to try to deceive people into thinking that a hard fork is merely a software change that is compatible with Bitcoin. It is not. It splits the network into 2 or more incompatible networks.
Core has no obligation to attempt to break the consensus rules. I don't know where you get the impression that they do. Anyone is free to fork Core's code and try to convince the community to join them. However, I urge everyone to oppose any fork that attempts to leverage miners against users. That raises serious ethical concerns about whether migrating users actually consent, or whether they felt forced by colluding miners (who have an apparent monopoly on hash rate and thus, confirmations for transactions).
"anyone is free to fork cores code"
hmm there you go again. subtle propaganda saying bitcoin is core and core is bitcoin, meaning anything not core, is not bitcoin.. seems you actually want core to be king and own bitcoin and make decisions without users consent, and you want anyone revolting away from your ideology to be classed as a alternative network/coin.
I didn't say "Bitcoin is Core and Core is Bitcoin." But it's the reference implementation. Why do you think XT, Classic and Unlimited are all forks of Core? What else would you expect people to fork, if not Core's repository? Feel free to code a new implementation from scratch, if you'd prefer.
but here is the thing that will trip you up..
orphans are the mechanism.. and orphans happen daily. meaning bitcoin is suppose to change but only in a direction the majority agree on.
so a true consensual fork is the same as the daily orphans.. the chain CONTINUES in the direction of the majority..
"Orphans" refer to valid blocks that don't have a known parent in the longest block chain. They don't refer to invalid blocks that aren't part of the Bitcoin network.
Also, you're only addressing processing power (miners). You're not addressing users at all. What gives miners power over the software that users decide to run? Nothing.
if someone makes a rule change by submitting a block with odd data using the real consensual mechanism, but doesnt have majority, it gets orphaned
every day there are decisions being made for which direction the majority should move.
so by your failed definition of the consensus mechanism.. the majority of users are moving to a different network every time there is a fork(orphan)..
No, an orphan doesn't imply a new network at all. Orphans are valid blocks, so they are compatible with the original network. Miners are simply agreeing on which
valid chain has the most cumulative work.
It seems you need a reminder of how this works:
http://cointimes.tech/2016/08/hard-forks-and-consensus-networks-meta-questions-and-limitations/http://www.gsd.inesc-id.pt/~ler/docencia/rcs1314/papers/P2P2013_041.pdfa controversial fork still gets orphaned off..
but.. only when intentionally blacklisting certain nodes to prevent the orphaning mechanism from taking care of the situation is where a realistic and continual split occur.
A fork that breaks the consensus rules doesn't get orphaned. It gets ignored. Saying that it is "orphaned" suggests it is valid according to the network. It isn't.
the community on the whole dont want a intentional split by adding in code to bypass the natural orphaning mechanism, all that is being said is a consensual fork for true capacity growth
which wont happen if core prevent a healthy majority by doing all this propaganda crap to keep their sheep inline to veto a change. and blindly allow another change by not telling their sheep its not requiring their consent for that route either
think long and hard about what i have just said.. and dont reply just with waffle to defend cores control
Core doesn't have any control. Please come to terms with the fact that most of the community supports Core's maintenance of the Bitcoin code. You may disagree with their views -- it's only natural in such a diverse ecosystem that not every participant sees eye to eye. But I'm becoming more and more confused as to what you are even arguing for.
Anyone is free to opt out of the network and run an incompatible node. Anyone is free to contribute to projects other than Bitcoin Core. Please feel free to support such efforts.
I only ask that people try to understand that leveraging miners against users to try to force a network migration (as XT and Classic attempted to do) is unethical, and I ask that people reflect on whether it is right for miners to provoke users into removing consensus rules. Hard forks are a matter of user consent, not miner consent. Miner consent only establishes the longest valid chain (so, it enables soft forks). It has nothing to do with the consensus rules that every node on the network enforces.
Many of us view the block size limit as a moral issue -- key to allowing Bitcoin to remain peer-to-peer and sufficiently decentralized to prevent attacks -- and further, that consensus rules must be safe from tyranny of the majority. For miners to leverage "fear of being on the weaker chain" against users to remove the block size limit, for me, is not very different from miners doing so to remove the 21M supply limit. This idea that consensus rules are subject to democratic vote is extremely dangerous, and I oppose it unequivocally.
And frankly, I don't think that you are convincing anyone here of anything -- your understanding of the protocol is clearly lacking and you are clearly very angry, which obviously gets in the way of your message.
