Re: Chinese Miners Revolt, Announces Plan to Hard Fork to Classic
What a load of shit. Must try harder young shill.
Here you are, scratching out a few satoshis by shilling shit gambling sites in your signature and avatar (what's it like, whoring yourself out for chump change?), and you got the nerve to call someone else a shill
Unless you have something more than your eye-raping ads & feeble ad hominems to add to the thread, please refrain from posting in the future.
He is a hero with over 600 activity, your a newbie with 14. Just by looking at his activity and rank, you can tell he contributed a lot more to the forum than you. You need to get out.
Also, 777 coin pays pretty damn well to their hero members.
First, take your signature spamming elsewhere, you are doing the same shit the other signature whore was reprehended for: Contributing nothing of substance and whoring a sig. Spamming your sig all over the forum is not contributing, it's pretty much the opposite of contributing.
To bring this back on topic: This is what started the whole thing:
https://np.reddit.com/r/Bitcoin/comments/4q3ztw/a_call_for_core_developers_to_clarify_their/d4q6ryh?context=3
Quote
[]luke-jrLuke Dashjr - Bitcoin Expert 2 points 17 hours ago
HaoBTC, in the future, if you have concerns or questions that need clarification and/or answering, please just ask, rather than posting on a blog that we probably don't read and might not even notice...
Things that we tried to make clear both at the meeting itself, as well as afterward on social media:
Core contributors present and party to the agreement were not acting as representatives of the Core dev team, (This was made VERY clear.)
There was no hardfork promised (not even all the Core dev team has authority to do that), only code that could be recommended for one. (This also was made VERY clear.)
The hardfork proposal promised was not a "2 MB hardfork", but a hardfork that would include as one minor change, the ability to include up to 2 MB of current witness-included-in-txid (anyone-can-malleate) transactions.
Miners have no leverage to make demands. If they attempt to hardfork without community consensus, they harm only themselves, while Bitcoin moves on without them. (At least for my part, my goal of the agreement was to end division and argumentation, which did not happen, admittedly not because of the fault of many of the agreement participants.)
The July 2016 estimate was not part of the agreement, and certainly not a deadline. It was (at the time) a reasonable expectation based on the agreement terms.
Speaking only for myself, I made the promise with sincerity, and intend to uphold it best I can (despite the almost immediate violation by one of the parties).
Admittedly, both at the meeting and now, I consider the "SegWit delayed until HF is released in Core" position some miners took to be unviable, and that miners will be pressured to deploy it much sooner by the community. After all, not deploying segwit literally means they are preventing the block size increase. However, I understand the agreement places no such obligation on them.
Since the agreement was made:
SegWit has still not yet been included in a release. Thus the three months deadline has not even begun "counting" yet. (I still aspire to have something by the end of July if possible, but I consider this to be above and beyond the agreed-on terms.)
Discussions have revealed that the goal of expanding space for anyone-can-malleate transactions loses the necessary performance improvements included with SegWit to make larger blocks safer, thus cannot safely be done without ugly hacks to introduce new limits similar to BIP 109 which might become a nuisance to Bitcoin both today and in the future. This isn't a show-stopper to writing code, but it may make it difficult to come up with something that unbiased parties can recommend.
Many third parties have expressed that they will under no conditions consent to a hardfork that comes out of this or any other political agreement. This won't block code nor recommentation, but it does guarantee such a proposal cannot be adopted.
Some developer(s) have expressed concerns that doing a hardfork safely ("soft hardfork") is somehow "unethical" to them, and doing it unsafely will require even greater efforts on ensuring consensus is reached not only from the community, but also that there are no nodes accidentally left behind. This isn't a blocker, but it probably makes deployment much harder.
HaoBTC, in the future, if you have concerns or questions that need clarification and/or answering, please just ask, rather than posting on a blog that we probably don't read and might not even notice...
Things that we tried to make clear both at the meeting itself, as well as afterward on social media:
Core contributors present and party to the agreement were not acting as representatives of the Core dev team, (This was made VERY clear.)
There was no hardfork promised (not even all the Core dev team has authority to do that), only code that could be recommended for one. (This also was made VERY clear.)
The hardfork proposal promised was not a "2 MB hardfork", but a hardfork that would include as one minor change, the ability to include up to 2 MB of current witness-included-in-txid (anyone-can-malleate) transactions.
Miners have no leverage to make demands. If they attempt to hardfork without community consensus, they harm only themselves, while Bitcoin moves on without them. (At least for my part, my goal of the agreement was to end division and argumentation, which did not happen, admittedly not because of the fault of many of the agreement participants.)
The July 2016 estimate was not part of the agreement, and certainly not a deadline. It was (at the time) a reasonable expectation based on the agreement terms.
Speaking only for myself, I made the promise with sincerity, and intend to uphold it best I can (despite the almost immediate violation by one of the parties).
Admittedly, both at the meeting and now, I consider the "SegWit delayed until HF is released in Core" position some miners took to be unviable, and that miners will be pressured to deploy it much sooner by the community. After all, not deploying segwit literally means they are preventing the block size increase. However, I understand the agreement places no such obligation on them.
Since the agreement was made:
SegWit has still not yet been included in a release. Thus the three months deadline has not even begun "counting" yet. (I still aspire to have something by the end of July if possible, but I consider this to be above and beyond the agreed-on terms.)
Discussions have revealed that the goal of expanding space for anyone-can-malleate transactions loses the necessary performance improvements included with SegWit to make larger blocks safer, thus cannot safely be done without ugly hacks to introduce new limits similar to BIP 109 which might become a nuisance to Bitcoin both today and in the future. This isn't a show-stopper to writing code, but it may make it difficult to come up with something that unbiased parties can recommend.
Many third parties have expressed that they will under no conditions consent to a hardfork that comes out of this or any other political agreement. This won't block code nor recommentation, but it does guarantee such a proposal cannot be adopted.
Some developer(s) have expressed concerns that doing a hardfork safely ("soft hardfork") is somehow "unethical" to them, and doing it unsafely will require even greater efforts on ensuring consensus is reached not only from the community, but also that there are no nodes accidentally left behind. This isn't a blocker, but it probably makes deployment much harder.