The Barry Silbert segwit2x agreement with >80% miner support.

[CoinCube]

As I've said before, most of core has said they'd support a block size increase but at a less frantic pace. I suspect the miners will maintain their pressure of their own hard fork claiming that core will backpedal on their agreement if they don't (as you said they claimed about the HK agreement - none of which actually happened.)

Hopefully the sides will be close enough at that point for Core and the NYA signalling miners to come to an arrangement perhaps agreeing to 2MB in exchange for pushing back the change two months or something.

[JayJuanGee]

As I've said before, most of core has said they'd support a block size increase but at a less frantic pace. I suspect the miners will maintain their pressure of their own hard fork claiming that core will backpedal on their agreement if they don't (as you said they claimed about the HK agreement - none of which actually happened.)

Hopefully the sides will be close enough at that point for Core and the NYA signalling miners to come to an arrangement perhaps agreeing to 2MB in exchange for pushing back the change two months or something.

I continue to wonder why there are so many folks who continue to assert that 2mb is needed and a kind of must and a kind of emergency, without even verifying how segwit plays out.  Causes me to tentatively conclude that there is likely some hidden agenda in regards to such a desire to implement something that really seems to be unnecessary - and whether the implementation of unnecessary is for governance reasons or just some kind of big business reasons seems to escape me.

[RoommateAgreement]

someone knowledgable and without drama, needs to make a summary topic of the situation and post it in this board. i see a lot of FUD and false information these days that is making my head spin.

the summary needs to cover a couple of questions:
1. what is the difference between SegWit and SegWit2x
2. why do people keep saying it is BU code, it is buggy, it will crash,...
3. who are working on it. is it tested
...

[-ck]

I continue to wonder why there are so many folks who continue to assert that 2mb is needed and a kind of must and a kind of emergency, without even verifying how segwit plays out.  Causes me to tentatively conclude that there is likely some hidden agenda in regards to such a desire to implement something that really seems to be unnecessary - and whether the implementation of unnecessary is for governance reasons or just some kind of big business reasons seems to escape me.

One major one is the belief that segwit provides "discounted" transactions because the fee is only related to their block space usage and not the segregated witness component which is not stored in the block. In some regards this is somewhat true as the resources required to store and transmit the data for a segwit transaction are slightly larger than an equivalent classic transaction. The argument against this is that the data need not be stored long term and that the actual computational complexity of segwit transactions is less than that of traditional transactions. Pools are hoping that a rapid change to 2MB blocks means most people will continue to use traditional transactions and the accompanying fee schedule. There was a lot of debate about what block weight and segwit transaction weighting should mean if core implemented 2MB+segwit themselves, but because they felt the argument for 2MB+segwit was a bait and switch exercise by miners they abandoned it. Which means the miners are implementing their own segwit2x without even really thinking about it, and leaving the alleged discounted transactions in. Funny...

The second major reason is that they've been arguing for so long that a bigger block is an easy, simple, safe way to scale that they can't change their minds now. It's hard to know if they're aware it's unnecessary and it's a massive saving-face exercise, or they still believe they're right about it, but the end result is the same.

Finally there's the concern that if they don't strike while the iron's hot, then we'll be stuck with 1MB+segwit only as a transaction expansion mechanism for the foreseeable future. Since there is no other hard scaling solution committed to the development timeline, in some respects this is also partially true. If we wait till another scaling solution comes around, and yet again it provides more discounted ways of increasing transaction capacity without a concomitant rise in fees, then rising fees as an incentive to miners are once again at risk.

In essence it's primarily about fees and secondarily about saving face.

[CoinCube]

I continue to wonder why there are so many folks who continue to assert that 2mb is needed and a kind of must and a kind of emergency, without even verifying how segwit plays out.  Causes me to tentatively conclude that there is likely some hidden agenda in regards to such a desire to implement something that really seems to be unnecessary - and whether the implementation of unnecessary is for governance reasons or just some kind of big business reasons seems to escape me.

Most of us are simple bitcoin holders and just want the issue to be resolved.

Most of us do not want the Chinese miners to take over the bitcoin code and trust Core to manage upgrades far more then we trust other groups that do not prioritize decentralization.

For those of us who have educated ourselves on the issue it is clear that a 2MB hardfork is not needed as some kind of emergency solution but it is equally clear that it is needed to maintain overall good will in the community especially the mining community.

Since everyone seems to agree that a blocksize increase will eventually be required as bitcoin grows and most people including core developers feel that the dangers of a single one time increase are manageable I am of the strong opinion that a 2MB hardfork rolled out and deployed by Core using their usual slow and complete vetting process would be far less damaging than telling the miners to go take a hike after SegWit is activated.

[d5000]

The second major reason is that they've been arguing for so long that a bigger block is an easy, simple, safe way to scale that they can't change their minds now. It's hard to know if they're aware it's unnecessary and it's a massive saving-face exercise, or they still believe they're right about it, but the end result is the same.

If you go down to the John Does (=non-Techies) that use Bitcoin, you will see that most of them are "apolitical" (often being upset about the whole scaling debate as such) and many of them have a preference for big-block solutions - because they are much easier to understand than Segwit, LN, sidechains and other alternative solutions.

I think the big-blocker miners' gamble takes much into account this fact. So they adopt their communication strategy to these people. The goal being to get the Core fraction into a minority position if they don't accept a hard fork for 2MB. If Core keeps being "stubborn" (from their POV) then they will promote aggressively their preferred implementation with the 2MB hardfork. If they can get exchanges on board that would promote the client upgrade, then six months are enough to get a large majority of the users to update their client to the 2MB version.

So for me it's mostly a power struggle: Miners want to secure their influence over the code. If this is legit or not is debatable, but it's an understandable position - I don't think it's only short term "face-saving", it's also part of a long term strategy.

Finally there's the concern that if they don't strike while the iron's hot, then we'll be stuck with 1MB+segwit only as a transaction expansion mechanism for the foreseeable future.

Agree.

[spartacusrex]

I'll be honest..

Judging by the banter on the bitcoin-dev list.. I think we're a long way from having a smooooth transition.

The devs have clearly rejected SegWit2x, whether or not the Miners have.

https://en.bitcoin.it/wiki/Segwit_support

I think the miners are playing this ALL wrong. Now they are saying they'll do segwit - but not in the safe way that's been planned for 2 years,but some new way ? They're total morons. I know 'face-saving' keeps getting brought up, but you can't save face, by being a dick.

Now we are looking at a situation were the miners are going to have to run NON-Core code.. that was knocked up in what, 8 weeks, since Core can't pin down what SegWit2x ACTUALLY IS, and neither can anyone else.

I think it's total madness, And certainly NOT what you want from the most stable reliable piece of code in existence..

..

This will end in tears.

(buy some popcorn if you like a weepy..!)

There is DEFINITELY going to be a chain split. Too many BIPS, too many dicks.

..

BUT - I will say this.. UASF certainly got things rolling.. 

[eXpl0sive]

Is there a blog or a link that summarises the current state of play in an easily understandable  way?

Thank you

I need it too, i found: https://bitcoinmagazine.com/articles/bip91-segwit-activation-kludge-should-keep-bitcoin-whole/

Thanks for the link, well-explained.

However one question remains: Does BIP91 use 2MB block size or 1MB?

[d5000]

However one question remains: Does BIP91 use 2MB block size or 1MB?

BIP91 is only a mechanism to assure that all miners that accept Segwit2x will also signal for the "traditional" Segwit (BIP141). It has not directly something to do with the 1MB vs. 2MB debate. If BIP91 is locked in, all miners that run that client will have the rule that they only mine blocks on chains where all blocks are signalling for Segwit.

Indirectly it has something to do, as miners that support the agreement are meant to use the Segwit2x code, and in this implementation the 2MB hard fork will be integrated. But a miner can perfectly run a custom client with BIP91 and without the 2MB part (as far as I understand it).

[ComputerGenie]

...Most of us do not want the Chinese miners to take over the bitcoin code and trust Core to manage upgrades far more then we trust other groups that do not prioritize decentralization...

The amount of irony in that sentence is enough to choke a woolly mammoth. 

[Searing]

However one question remains: Does BIP91 use 2MB block size or 1MB?

BIP91 is only a mechanism to assure that all miners that accept Segwit2x will also signal for the "traditional" Segwit (BIP141). It has not directly something to do with the 1MB vs. 2MB debate. If BIP91 is locked in, all miners that run that client will have the rule that they only mine blocks on chains where all blocks are signalling for Segwit.

Indirectly it has something to do, as miners that support the agreement are meant to use the Segwit2x code, and in this implementation the 2MB hard fork will be integrated. But a miner can perfectly run a custom client with BIP91 and without the 2MB part (as far as I understand it).

My head hurts...but from my limited programming (basic on a 1976 apple ][)

the emergent consensus will get everyone on board to turn on seg witness, but it will have nothing to do at this time for doing a 2mb hard fork which they want

thus can't bitcoin core or someone ...let emergent consensus work in their favor and then simply have enough clout to block a future 2mb hard fork anyway

if this is so, emergent consensus signaling is simply a face-saving measure to get seg witness up by those who want a 2mb block and hope reasonableness wins later with bitcoin core

and hard fork of 2mb? In other words this whole cluster of 2mb hard forks would again rear its ugly head with no real solutions?

Again.....just trying to follow all this in my limited manner (I work with dev disabled deaf-blind folk..how I fell into techy miner stuff is anyone's guess)

[ComputerGenie]

...thus can't bitcoin core or someone ...let emergent consensus work in their favor and then simply have enough clout to block a future 2mb hard fork anyway...

My thinking is that they will do just that; by slinging unfounded accusations and innuendo, they will find a way to make it appear as though the "bad guys" are the only ones that want 2MB blocks (much like the "bad guys" currently need to be stopped from using "covert asicboost" [despite no evidence ever being presented that "covert asicboost" is even a thing that has ever been done]).

[-ck]

the emergent consensus will get ...

Emergent consensus has nothing to do with this. Forget anything to do with BU, that's been long forgotten by the power players. Any reference to EC in their block signature is there for legacy reasons and doesn't remotely mean they're interested in BU any more. BU supporters will insist this isn't the end for them and that it's still compatible with segwit2x, but then so is XT, classic and any other defunct attempt at a takeover from the past that never activates and stays on the current chain waiting to take it over at some unforeseen parallel universe future. Forget EC.

[CoinCube]

...Most of us do not want the Chinese miners to take over the bitcoin code and trust Core to manage upgrades far more then we trust other groups that do not prioritize decentralization...

The amount of irony in that sentence is enough to choke a woolly mammoth.  

Reality is reality.

Decentralization is an ideal something we approximate rather than achieve.
Specialized technical challenges necessitates leadership.

Making sure the power of those leaders is limited and used to sustain rather then undermine decentralization is the job of all community members.

Right now Core is full of early adopters who have a large position in bitcoin. This gives them an incentive for bitcoin to succeed and to refrain from undermining what decentralization we do have. They also have a mostly open and transparent development process and a large loosely bound group of technically skilled and active contributors. Overall this makes them the cleanest dirty shirt in the laundry basket.

That said it is good to remind Core on occasion that they are the stewards not the controllers of bitcoin. It is also good  to keep the miners happy so they feel their economic concerns are addressed. Thus I would like to see Core adopt and release a 2Mb blocksize increase (on Core code) after SegWit is active as this appears to me to be the healthiest way forward. Whether that will happen or not remains to be seen.

[ComputerGenie]

Continuing to centralize Bitcoin around the ideals of Core is centralization, no mater how you look at it. The idea of centralizing the "authority" of the code-base in order to stop the code-base from being centralized by "opposition" is steeped in a level of irony for which there are no words.
I'm all for folks making their position that Core has a "right" or "duty" (or even the false claim of "most qualified") to be the "authority" of the protocol, but please be honest in your claims and not use the false guise of "decentralization" as your reason for centralization. 

[CoinCube]

please be honest in your claims and not use the false guise of "decentralization" as your reason for centralization.  

Some level of top-down control is necessary to maintain self-organization in complex systems. This is a uniform truth that holds for all systems. The goal is to minimize the control while simultaneously preventing chaos from destroying the system.

If you are interested in a deeper analysis of this point I looked at the mathematics in the context of life and mutation rate here:

The Math of Optimal Fitness

[ComputerGenie]

Some level of top-down control is necessary to maintain self-organization in complex systems. This is a uniform truth that holds for all systems. The goal is to minimize the control while simultaneously preventing chaos from destroying the system...

I'm not saying that "someone" shouldn't be the "authority" of the protocol, or even (in this particular instance) that the "someone" shouldn't be Core. I am saying that many of the "arguments" I read (and the relevant picture they paint) is akin to saying "I'm going to eat tomato ketchup so that I'm not eating any tomato products". 
If you want Core to be in control, because you think Core can be the best control, then fine; however, don't dress it up in a pretty pink tutu and blow smoke up my ass about it. 

[CoinCube]

...
If you want Core to be in control, because you think Core can be the best control, then fine; however, don't dress it up in a pretty pink tutu and blow smoke up my ass about it.  

I want Core to be in authority because at this juncture they are the least bad option. They will exercise a higher level of restraint (lower overall control) then other contenders for authority while preventing chaos from destroying the system (I hope).

I believe I referred to them as a dirty shirt in the laundry basket immediately upthread so I can hardly be accused of dressing them up in a pretty pink tutu. That said the Chinese miner shirt looks much dirtier with something of a foul smell so for now I will stick with Core.

If the Core shirt gets a lot uglier with time aka corrupt or if some magically clean shirt comes along like transparent and fair AI I would jump ship but neither of these appear likely in the immediate future.

The goal is to maintain self-organization while minimizing control. Thus I am here in this thread for the sole purpose of encouraging Core to use their control to grant concessions where possible to the miners because ultimately this both secures Core's authority while minimizing it which is good for bitcoin.

[ComputerGenie]

I want Core to be in authority because at this juncture they are the least bad option...

Well, we agree on that much. 

[-ck]

83.3% support now with NYA in their coinbase so it's reached activation levels. This has been helped by bitclubnetwork joining them, however they've also actually started the real signalling on bit4/1 that activates it in mid-july. The reason is that the admin of that pool is the one that defined BIP91 and wrote the code for it so he's the first to use it as more than just proof of concept.