Does anyone else think this could have been nothing more then just a PR stunt, to pump bitcoin?
I mean they can't really think will fall for this this crap can they?
I think this was ment to target investors not the bitcoin user base.
This has to be some PR bullshit to get VC money.
Topic: The Barry Silbert segwit2x agreement with >80% miner support. - page 72. (Read 120033 times)
I believe what this plan is all about is to divide and rule, there is no sense in not involving Core developers, you want to implement Segwit that was developed by Core without carrying them along. It is a frustrating thing to see your transaction not been moved for 24hrs but this agreement is a perfect disagreement
This dispute is the natural result and challenge inherent in government by consensus. There is a reason that no human society has used government by consensus in the past. Its far easier to simply use force to subdue your opponents or get 51% of the voters to vote you power over your opponents.
This is why "government by consensus" if there is no central government, is immutability, THE invention of decentralized crypto.
I did not read through the entire thread out of sheer laziness but I will later.
For now I ask, why not activate Core's Segwit via soft fork now and then have new rounds of talks again for a hard fork to bigger block sizes? It would be better to do things conservatively than risk splitting the blockchain in 2.
For now I ask, why not activate Core's Segwit via soft fork now and then have new rounds of talks again for a hard fork to bigger block sizes? It would be better to do things conservatively than risk splitting the blockchain in 2.
That's the whole point of the "civil war."
If seggy gets activated then who's to say the Core will turn their back on increasing blocksize. Blocksize increase is simple and must come first.
The HK agreement was botched and didn't include everyone. If we had a revamped agreement with all necessary parties signing on to be accountable then we can get some real traction. (assuming BU can ever deal with segwit being added via soft fork and assuming Core can deal with a blocksize increase).
so is this ASICBOOST proof then? if so, why did Bitmain agree?
And why was Core not invited?
And why was Core not invited?
It's not asicboost proof because its not really a soft fork of segwit first (even though some people are purposefully trying to confuse others to think differently).
I did not read through the entire thread out of sheer laziness but I will later.
For now I ask, why not activate Core's Segwit via soft fork now and then have new rounds of talks again for a hard fork to bigger block sizes? It would be better to do things conservatively than risk splitting the blockchain in 2.
For now I ask, why not activate Core's Segwit via soft fork now and then have new rounds of talks again for a hard fork to bigger block sizes? It would be better to do things conservatively than risk splitting the blockchain in 2.
That's the whole point of the "civil war."
If seggy gets activated then who's to say the Core will turn their back on increasing blocksize. Blocksize increase is simple and must come first.
For now I ask, why not activate Core's Segwit via soft fork now and then have new rounds of talks again for a hard fork to bigger block sizes? It would be better to do things conservatively than risk splitting the blockchain in 2.
What you are proposing is what core has been offering all along... 
I did not read through the entire thread out of sheer laziness but I will later.
For now I ask, why not activate Core's Segwit via soft fork now and then have new rounds of talks again for a hard fork to bigger block sizes? It would be better to do things conservatively than risk splitting the blockchain in 2.
For now I ask, why not activate Core's Segwit via soft fork now and then have new rounds of talks again for a hard fork to bigger block sizes? It would be better to do things conservatively than risk splitting the blockchain in 2.
That would be far too easy with little room for flexing or grabbing power.
So is this really a plan to dump the Core developers and they place a new group of developers under their payroll to become "stewards" of the network?
I might start my long delayed plan of buying into an altcoin now. Any suggestions?
I did not read through the entire thread out of sheer laziness but I will later.
For now I ask, why not activate Core's Segwit via soft fork now and then have new rounds of talks again for a hard fork to bigger block sizes? It would be better to do things conservatively than risk splitting the blockchain in 2.
For now I ask, why not activate Core's Segwit via soft fork now and then have new rounds of talks again for a hard fork to bigger block sizes? It would be better to do things conservatively than risk splitting the blockchain in 2.
That would be far too easy with little room for flexing or grabbing power.
I did not read through the entire thread out of sheer laziness but I will later.
For now I ask, why not activate Core's Segwit via soft fork now and then have new rounds of talks again for a hard fork to bigger block sizes? It would be better to do things conservatively than risk splitting the blockchain in 2.
For now I ask, why not activate Core's Segwit via soft fork now and then have new rounds of talks again for a hard fork to bigger block sizes? It would be better to do things conservatively than risk splitting the blockchain in 2.
...Fed up with seeing no block for 30 minutes then 3 blocks in 10 minutes. It makes confirmation time yo yo unpredictable.
That's likely to happen no matter what the diff is. ...Far better would be to achieve widespread consensus around some compromise that is not perfect but is "good enough for now"...
Isn't that the mentality that got us in this 1MB size mess in the 1st place (not perfect but "good enough for now")? 
The 1MB blocks size is not a mess. If it was not the 1MB block size it would be something else later on.
This dispute is the natural result and challenge inherent in government by consensus. There is a reason that no human society has used government by consensus in the past. Its far easier to simply use force to subdue your opponents or get 51% of the voters to vote you power over your opponents.
Personally I would supports SegWit + 2Mb block fork provided the code was vetted and tested by the Bitcoin Core team and was supported by 95% of the available hashing power and all the major exchanges.
I believe Bitcoin Core's vision of scaling is ultimately the correct one but no one has convinced me that we cannot afford to throw the big block folks a bone in order to keep things moving along smoothly.
But I am not a technical expert and if someone can present a compelling case why SegWit + 2Mb would significantly damage the network or it becomes clear that it is impossible for SegWit + 2Mb to ever achieve consensus I would change my mind.
I still can't reconcile this ridiculous notion that everyone is arguing over 'SegWit with 1MB stab in the dark' or 'SegWit with 2MB stab in the dark' when both options are shortsighted, involve too much rigidity and are guaranteed to require further hardforks in future. Why not just do one hardfork allowing for a slow and gentle ease of pressure?
Both camps have clearly already decided on central planning to dictate or coerce whether it's going to be on-chain or off-chain scaling and we seemingly have a binary choice between the two stupid extremes. Neither wants to let the market choose freely and decide for itself how best to grow. I'd argue that both sides are spineless cowards in this regard.
The "civil war" is a bizarre one. If 2mb seggy hardfork, might as well do a difficulty retargeting adjustment too. Fed up with seeing no block for 30 minutes then 3 blocks in 10 minutes. It makes confirmation time yo yo unpredictable.
so is this ASICBOOST proof then? if so, why did Bitmain agree?
If they wish to replace the existing soft fork implementation of segwit with their hard fork implementation then it will still allow covert asicboost to work. Of course this isn't evidence that they are using it or plan to but it certainly doesn't help suspicions... so is this ASICBOOST proof then? if so, why did Bitmain agree?
And why was Core not invited?
No, one has nothing to do with the other (despite the rumors, unfounded accusations, and wild conspiracy theories). Given that they are still pushing BU blocks at Antpool, I'm not entirely convinced that they did. And because they don't have to be. And why was Core not invited?
The 1MB blocks size is not a mess. If it was not the 1MB block size it would be something else later on.
This dispute is the natural result and challenge inherent in government by consensus. There is a reason that no human society has used government by consensus in the past. Its far easier to simply use force to subdue your opponents or get 51% of the voters to vote you power over your opponents.
Personally I would supports SegWit + 2Mb block fork provided the code was vetted and tested by the Bitcoin Core team and was supported by 95% of the available hashing power and all the major exchanges.
I believe Bitcoin Core's vision of scaling is ultimately the correct one but no one has convinced me that we cannot afford to throw the big block folks a bone in order to keep things moving along smoothly.
But I am not a technical expert and if someone can present a compelling case why SegWit + 2Mb would significantly damage the network or it becomes clear that it is impossible for SegWit + 2Mb to ever achieve consensus I would change my mind.
I still can't reconcile this ridiculous notion that everyone is arguing over 'SegWit with 1MB stab in the dark' or 'SegWit with 2MB stab in the dark' when both options are shortsighted, involve too much rigidity and are guaranteed to require further hardforks in future. Why not just do one hardfork allowing for a slow and gentle ease of pressure?
Both camps have clearly already decided on central planning to dictate or coerce whether it's going to be on-chain or off-chain scaling and we seemingly have a binary choice between the two stupid extremes. Neither wants to let the market choose freely and decide for itself how best to grow. I'd argue that both sides are spineless cowards in this regard.
Some parties that are have argued that ever increasing block sizes will lead to progressive centralization over time. Bigger block folks disagree.
Regardless of the underlying truth no matter what is decided we will face hard forks in the future. For bitcoin to grow
there are certain to be multiple necessary upgrades along the way some of which will require hard forks.
There is no avoiding this challenge by forcing though single automatic scaling algorithm and hoping for the best.
The fact that their is not widespread consensus currently for on-chain or off-chain scaling is yet another reason to support a compromise position along the lines of SegWit + 2Mb. It give both sides time to show what their solution offers without fundamentally committing us to either.
...Far better would be to achieve widespread consensus around some compromise that is not perfect but is "good enough for now"...
Isn't that the mentality that got us in this 1MB size mess in the 1st place (not perfect but "good enough for now")? The 1MB blocks size is not a mess. If it was not the 1MB block size it would be something else later on.
This dispute is the natural result and challenge inherent in government by consensus. There is a reason that no human society has used government by consensus in the past. Its far easier to simply use force to subdue your opponents or get 51% of the voters to vote you power over your opponents.
Personally I would supports SegWit + 2Mb block fork provided the code was vetted and tested by the Bitcoin Core team and was supported by 95% of the available hashing power and all the major exchanges.
I believe Bitcoin Core's vision of scaling is ultimately the correct one but no one has convinced me that we cannot afford to throw the big block folks a bone in order to keep things moving along smoothly.
But I am not a technical expert and if someone can present a compelling case why SegWit + 2Mb would significantly damage the network or it becomes clear that it is impossible for SegWit + 2Mb to ever achieve consensus I would change my mind.
I still can't reconcile this ridiculous notion that everyone is arguing over 'SegWit with 1MB stab in the dark' or 'SegWit with 2MB stab in the dark' when both options are shortsighted, involve too much rigidity and are guaranteed to require further hardforks in future. Why not just do one hardfork allowing for a slow and gentle ease of pressure?
Both camps have clearly already decided on central planning to dictate or coerce whether it's going to be on-chain or off-chain scaling and we seemingly have a binary choice between the two stupid extremes. Neither wants to let the market choose freely and decide for itself how best to grow. I'd argue that both sides are spineless cowards in this regard.
so is this ASICBOOST proof then? if so, why did Bitmain agree?
And why was Core not invited?
And why was Core not invited?
The 1MB blocks size is not a mess..
True, because having 110MB of unconfirmed transactions is just great. 
Of course it's not great it's a problem that needs to be solved.
This is an important moment in history. If the Devs fuck up there are a lot of others waiting in the wings to pick up where they left off.
The 1MB blocks size is not a mess..
True, because having 110MB of unconfirmed transactions is just great. Jump to: