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

[BitcoinNewsMagazine]

Is BTC.com owned by Bitmain? These guys are signalling SW instead of BIP91. Not that it's a huge issue now, but I was just curious.

Yes Bitmain launched BTC.com and mining pool in 2016.

[1714896745]

1714896745

[1714896745]

1714896745

[1714896745]

1714896745

[-ck]

They did this in the hope they could get their (useless) block size increase after activating segwit. However there is absolutely nothing that guarantees the lock in of the hard fork 3 months from now based on bit 4 being active at the moment

The *only* useful thing that could come out of this is that bitcoin could finally jailbreak out of the 1 MB artificial lock-up, and segwit is in fact making this worse by trying to increase a very last time the amount of transactions per block, by delegating part of the block data outside of the "official" block size, but this cannot, as far as I understand, be extended yet another time.  In other words, segwit is the "end of the road" for more transactions if the jail of 1 MB blocks remains.  Yes, it will get us some temporary relief, but on the other hand, it has graved even more into stone the 1 MB limit and the "danger of hard forks" (which is a non-issue in most other crypto coins which do this regularly).

Once you break the jail once, you're free for ever.  However, if bitcoin doesn't succeed in overcoming this silly 1 MB limit now, it may even be much, much harder in the future to do so ; this is why it is of utmost importance that 2 MB blocks (with or without segwit) are adopted, to kill this 1 MB hard wall once and for all.

That doesn't solve fundamentally the essential design flaws in bitcoin, but at least, it doesn't turn a silly error into yet another extra fundamental design flaw for ever (I'm talking about the 1 MB limit).

You misunderstand me, probably because of my flamebait "useless" comment. I'm for a 2MB hard fork and said so earlier in this thread. What I'm against is a rushed hard fork done by morons who don't understand the code they're modifying earlier than is needed. Once segwit locks in it will ease the pressure on transactions for the time being - and there actually ISN'T any pressure on transactions now that the artificial spamming is over. I'd be for a hard fork in 12 months from now, done with the cooperation of core instead of rushed by outsiders forking the code and missing out on other developments in the code. The bulk of the core group has said they'd push for 2MB in the past, BUT the pressure in all directions is making all this information obscured.

[xyzzy099]

Is BTC.com owned by Bitmain? These guys are signalling SW instead of BIP91. Not that it's a huge issue now, but I was just curious.

Coinbase
EzrY/BTC.COM/NYA/...4$

That "NYA" doesn't really signal anything meaningful, other than general support for an idea.  The block version they are mining is "$20000002" which indicates segwit support, but not BIP91 support.  Most miners are currently signalling both segwit and BIP91 by using version "$200000012".

[allinvain]

I see that now since BIP91 is locked in, the % of miners signaling has gone down. Interesting.

[pooya87]

I see that now since BIP91 is locked in, the % of miners signaling has gone down. Interesting.

maybe it is just fluctuations since the percentage is not that big yet to mean anything.
or maybe it is because they stopped signalling for BIP91 since it was no longer needed, or maybe by mistake and switched to signalling BIP141 only
changed version bit from 0x20000010 to 0x20000002 (see BTC.com for example #476818 #476948)

[Sithara007]

I see that now since BIP91 is locked in, the % of miners signaling has gone down. Interesting.

Yeah.. now it is around 85%. But now the attention seems to have shifted to BIP 141, which is having around 95.1% support now (95.0% support needed to lock in BIP 141). All the blocks seems to be signaling BIP 141 without exception.

[-ck]

I see that now since BIP91 is locked in, the % of miners signaling has gone down. Interesting.

Yeah.. now it is around 85%. But now the attention seems to have shifted to BIP 141, which is having around 95.1% support now (95.0% support needed to lock in BIP 141). All the blocks seems to be signaling BIP 141 without exception.

Signalling bit 4 AKA BIP91 serves no purpose now that its action is locked in. The important part is enforcing it, meaning rejecting any blocks that don't have bit 1 AKA BIP141 set. On the other hand, bit 4 is meant to be signalled up to the time of the 2x hard fork so pools dropping it now might mean something. More likely it's just shuffling of coin daemon code/settings.

[pooya87]

seems like ALL the miners are signalling for BIP141 apart from some of those no-hashrate-miners
not signalling:
Canoe 0.8%
ConnectBTC: 1.1%

[Troll Buster]

All these Core fan bois talking about NYA signatories pulling another Blockstream bait and switch, means even a Core fan boy believes BS/Core and small blockers are a bunch of lying fks and can't be trusted.

That's the truth and the Core fan bois know it.

What the Core fan boys also don't understand is 2MB was never a big deal for most parties other than Blockstream.

Even from a side chain business pov, by the time side chain technology is ready 2MB blocks will be full, and the same small block bullshit excuses can start all over again.

Yes Segwit is a piece of shit, many miners hate it, it has See Eye Aye written all over it and a lot of resources and tactics were used to worm Segwit into Core's code base.

From miners' pov they don't really care what other people do as long as Bitcoin remain strong and continue to grow, that's why miners agreed to SegWit in 2016.

But idiots from Blockstream over played their hand when they had no hash power and had no development power to deliver a working product on time.

Then of course there was the fact that Bitcoin was becoming a threat to certain powers and it was time to fund another coin like ETH and play divide and conquer.

If I am running the show at See Eye Aye I'd get some friends to fund something like ETH and make sure everyone else at BTC is arguing over stupid shit, every side is smeared, create crisis after crisis while ETH rise like a rocket, tell the friends to cash out then release a known bug so the market crashes, then start buying again.

Actually I'd also fund a 3rd coin along the way so none of the top 3 can ever reach 35% dominance. Then the old boys club VISA and others can play I-am-late-but-me-too at 5% market share and still won't look like a midget.

As Andreas said in one of his video every grassroots organization is infiltrated by the Cocaine Import Agency, money runs the world and you can bet extra attention is paid on something like a Bitcoin community.

As for the 90 days 2MB hard fork, yes, over half of the NYA signatory can ruin their reputation and pull another Blockstream bait and switch, but that's just a bad move only Blockstream/Core and their fan bois would think of pulling, not everyone is as brain dead as Adam and Greg, 2MB is not worth ruining reputation over, 2MB allows Bitcoin to grow, so by the time side chain is ready, there is a bigger market for side chain.

2MB is good for everybody except Blockstream.

If anyone wants to know why Blockstream over played their hand, this reddit post sums it up:

https://np.reddit.com/r/Buttcoin/comments/6ndfut/buttcoin_is_decentralized_in_5_nodes/dk9c27f/
Core/Blockstream/Greg Maxwell explained. Great post by JStfolfi (np.reddit.com)
submitted 6 days ago by jonald_fyookball

jstolfi 160 points 6 days ago*

In my understanding, allowing Luke to run his node is not the reason, but only an excuse that Blockstream has been using to deny any actual block size limit increase.

The actual reason, I guess, is that Greg wants to see his "fee market" working. It all started on Feb/2013. Greg posted to bitcointalk his conclusion that Satoshi's design with unlimited blocks was fatally flawed, because, when the block reward dwindled, miners would undercut each other's transaction fees until they all went bakrupt. But he had a solution: a "layer 2" network that would carry the actual bitcoin payments, with Satoshi's network being only used for large sporadic settlements between elements of that "layer 2".

(At the time, Greg assumed that the layer 2 would consist of another invention of his, "pegged sidechains" -- altcoins that would be backed by bitcoin, with some cryptomagic mechanism to lock the bitcoins in the main blockchain while they were in use by the sidechain. A couple of years later, people concluded that sidechains would not work as a layer 2. Fortunately for him, Poon and Dryja came up with the Lightning Network idea, that could serve as layer 2 instead.)

The layer 1 settlement transactions, being relatively rare and high-valued, supposedly could pay the high fees needed to sustain the miners. Those fees would be imposed by keeping the block sizes limited, so that the layer-1 users woudl have to compete for space by raising their fees. Greg assumed that a "fee market" would develop where users could choose to pay higher fees in exchange of faster confirmation.

Gavin and Mike, who were at the time in control of the Core implementation, dismissed Greg's claims and plans. In fact there were many things wrong with them, technical and economical. Unfortunately, in 2014 Blockstream was created, with 30 M (later 70 M) of venture capital -- which gave Greg the means to hire the key Core developers, push Gavin and Mike out of the way, and make his 2-layer design the official roadmap for the Core project.

Greg never provided any concrete justification, by analysis or simulation, for his claims of eventual hashpower collapse in Satoshi's design or the feasibility of his 2-layer design.

On the other hand, Mike showed, with both means, that Greg's "fee market" would not work. And, indeed, instead of the stable backlog with well-defined fee x delay schedule, that Greg assumed, there is a sequence of huge backlogs separated by periods with no backlog.

During the backlogs, the fees and delays are completely unpredictable, and a large fraction of the transactions are inevitably delayed by days or weeks. During the intemezzos, there is no "fee market' because any transaction that pays the minimum fee (a few cents) gets confirmed in the next block.

That is what Mike predicted, by theory and simulations -- and has been going on since Jan/2016, when the incoming non-spam traffic first hit the 1 MB limit. However, Greg stubbornly insists that it is just a temporary situation, and, as soon as good fee estimators are developed and widely used, the "fee market" will stabilize. He simply ignores all arguments of why fee estimation is a provably unsolvable problem and a stable backlog just cannot exist. He desperately needs his stable "fee market" to appear -- because, if it doesn't, then his entire two-layer redesign collapses.

That, as best as I can understand, is the real reason why Greg -- and hence Blockstream and Core -- cannot absolutely allow the block size limit to be raised. And also why he cannot just raise the minimum fee, which would be a very simple way to reduce frivolous use without the delays and unpredictability of the "fee market".

Before the incoming traffic hit the 1 MB limit, it was growing 50-100% per year. Greg already had to accept, grudgingly, the 70% increase that would be a side effect of SegWit. Raising the limit, even to a miser 2 MB, would have delayed his "stable fee market" by another year or two. And, of course, if he allowed a 2 MB increase, others would soon follow.

Hence his insistence that bigger blocks would force the closure of non-mining relays like Luke's, which (he incorrectly claims) are responsible for the security of the network, And he had to convince everybody that hard forks -- needed to increase the limit -- are more dangerous than plutonium contaminated with ebola.

SegWit is another messy imbroglio that resulted from that pile of lies. The "malleability bug" is a flaw of the protocol that lets a third party make cosmetic changes to a transaction ("malleate" it), as it is on its way to the miners, without changing its actual effect.

The malleability bug (MLB) does not bother anyone at present, actually. Its only serious consequence is that it may break chains of unconfirmed transactions, Say, Alice issues T1 to pay Bob and then immediately issues T2 that spends the return change of T1 to pay Carol. If a hacker (or Bob, or Alice) then malleates T1 to T1m, and gets T1m confirmed instead of T1, then T2 will fail.

However, Alice should not be doing those chained unconfirmed transactions anyway, because T1 could fail to be confirmed for several other reasons -- especially if there is a backlog.

On the other hand, the LN depends on chains of the so-called bidirectional payment channels, and these essentially depend on chained unconfirmed transactions. Thus, given the (false but politically necessary) claim that the LN is ready to be deployed, fixing the MB became a urgent goal for Blockstream.

There is a simple and straightforward fix for the MLB, that would require only a few changes to Core and other blockchain software. That fix would require a simple hard fork, that (like raising the limit) would be a non-event if programmed well in advance of its activation.

But Greg could not allow hard forks, for the above reason. If he allowed a hard fork to fix the MLB, he would lose his best excuse for not raising the limit. Fortunately for him, Pieter Wuille and Luke found a convoluted hack -- SegWit -- that would fix the MLB without any hated hard fork.

Hence Blockstream's desperation to get SegWit deployed and activated. If SegWit passes, the big-blockers will lose a strong argument to do hard forks. If it fails to pass, it would be impossible to stop a hard fork with a real limit increase.

On the other hand, SegWit needed to offer a discount in the fee charged for the signatures ("witnesses"). The purpose of that discount seems to be to convince clients to adopt SegWit (since, being a soft fork, clients are not strictly required to use it). Or maybe the discount was motivated by another of Greg's inventions, Confidential Transactions (CT) -- a mixing service that is supposed to be safer and more opaque than the usual mixers. It seems that CT uses larger signatures, so it would especially benefit from the SegWit discount.

Anyway, because of that discount and of the heuristic that the Core miner uses to fill blocks, it was also necessary to increase the effective block size, by counting signatures as 1/4 of their actual size when checking the 1 MB limit. Given today's typical usage, that change means that about 1.7 MB of transactions will fit in a "1 MB" block. If it wasn't for the above political/technical reasons, I bet that Greg woudl have firmly opposed that 70% increase as well.

If SegWit is an engineering aberration, SegWit2X is much worse. Since it includes an increase in the limit from 1 MB to 2 MB, it will be a hard fork. But if it is going to be a hard fork, there is no justification to use SegWit to fix the MLB: that bug could be fixed by the much simpler method mentioned above.

And, anyway, there is no urgency to fix the MLB -- since the LN has not reached the vaporware stage yet, and has yet to be shown to work at all.

[Meuh6879]

Update : https://www.xbt.eu/ (144 Blocks)

[hv_]

All these Core fan bois talking about NYA signatories pulling another Blockstream bait and switch, means even a Core fan boy believes BS/Core and small blockers are a bunch of lying fks and can't be trusted.

That's the truth and the Core fan bois know it.

What the Core fan boys also don't understand is 2MB was never a big deal for most parties other than Blockstream.

Even from a side chain business pov, by the time side chain technology is ready 2MB blocks will be full, and the same small block bullshit excuses can start all over again.

Yes Segwit is a piece of shit, many miners hate it, it has See Eye Aye written all over it and a lot of resources and tactics was used to worm Segwit into Core's code base.

From miners' pov they don't really care what other people do as long as Bitcoin remain strong and continue to grow, that's why miners agreed to SegWit in 2016.

But idiots from Blockstream over played their hand when they had no hash power and had no development power to deliver a working product on time.

Then of course there was the fact that Bitcoin was becoming a threat to certain powers and it was time to fund another coin like ETH and play divide and conquer.

If I am running the show at See Eye Aye I'd get some friends to fund something like ETH and make sure everyone else at BTC is arguing over stupid shit, every side is smeared, create crisis after crisis while ETH rise like a rocket, tell the friends to cash out then release a known bug so the market crashes, then start buying again.

Actually I'd also fund a 3rd coin along the way so none of the top 3 can ever reach 35% dominance. Then the old boys club VISA and others can play I-am-late-but-me-too at 5% market share and still won't look like a midget.

As Andreas said in one of his video every grassroots organization is infiltrated by the Cocaine Import Agency, money runs the world and you can bet extra attention is paid on something like a Bitcoin community.

As for the 90 days 2MB hard fork, yes, over half of the NYA signatory can ruin their reputation and pull another Blockstream bait and switch, but that's just a bad move only Blockstream/Core and their fan bois would think of using, 2MB is not worth ruining reputation over, not everyone is as brain dead as Adam and Greg.

2MB is good for everybody except Blockstream.

If anyone wants to know why Blockstream over played their hand, this reddit post sums it up:

https://np.reddit.com/r/Buttcoin/comments/6ndfut/buttcoin_is_decentralized_in_5_nodes/dk9c27f/

jstolfi 160 points 6 days ago*

In my understanding, allowing Luke to run his node is not the reason, but only an excuse that Blockstream has been using to deny any actual block size limit increase.

The actual reason, I guess, is that Greg wants to see his "fee market" working. It all started on Feb/2013. Greg posted to bitcointalk his conclusion that Satoshi's design with unlimited blocks was fatally flawed, because, when the block reward dwindled, miners would undercut each other's transaction fees until they all went bakrupt. But he had a solution: a "layer 2" network that would carry the actual bitcoin payments, with Satoshi's network being only used for large sporadic settlements between elements of that "layer 2".

(At the time, Greg assumed that the layer 2 would consist of another invention of his, "pegged sidechains" -- altcoins that would be backed by bitcoin, with some cryptomagic mechanism to lock the bitcoins in the main blockchain while they were in use by the sidechain. A couple of years later, people concluded that sidechains would not work as a layer 2. Fortunately for him, Poon and Dryja came up with the Lightning Network idea, that could serve as layer 2 instead.)

The layer 1 settlement transactions, being relatively rare and high-valued, supposedly could pay the high fees needed to sustain the miners. Those fees would be imposed by keeping the block sizes limited, so that the layer-1 users woudl have to compete for space by raising their fees. Greg assumed that a "fee market" would develop where users could choose to pay higher fees in exchange of faster confirmation.

Gavin and Mike, who were at the time in control of the Core implementation, dismissed Greg's claims and plans. In fact there were many things wrong with them, technical and economical. Unfortunately, in 2014 Blockstream was created, with 30 M (later 70 M) of venture capital -- which gave Greg the means to hire the key Core developers, push Gavin and Mike out of the way, and make his 2-layer design the official roadmap for the Core project.

Greg never provided any concrete justification, by analysis or simulation, for his claims of eventual hashpower collapse in Satoshi's design or the feasibility of his 2-layer design.

On the other hand, Mike showed, with both means, that Greg's "fee market" would not work. And, indeed, instead of the stable backlog with well-defined fee x delay schedule, that Greg assumed, there is a sequence of huge backlogs separated by periods with no backlog.

During the backlogs, the fees and delays are completely unpredictable, and a large fraction of the transactions are inevitably delayed by days or weeks. During the intemezzos, there is no "fee market' because any transaction that pays the minimum fee (a few cents) gets confirmed in the next block.

That is what Mike predicted, by theory and simulations -- and has been going on since Jan/2016, when the incoming non-spam traffic first hit the 1 MB limit. However, Greg stubbornly insists that it is just a temporary situation, and, as soon as good fee estimators are developed and widely used, the "fee market" will stabilize. He simply ignores all arguments of why fee estimation is a provably unsolvable problem and a stable backlog just cannot exist. He desperately needs his stable "fee market" to appear -- because, if it doesn't, then his entire two-layer redesign collapses.

That, as best as I can understand, is the real reason why Greg -- and hence Blockstream and Core -- cannot absolutely allow the block size limit to be raised. And also why he cannot just raise the minimum fee, which would be a very simple way to reduce frivolous use without the delays and unpredictability of the "fee market".

Before the incoming traffic hit the 1 MB limit, it was growing 50-100% per year. Greg already had to accept, grudgingly, the 70% increase that would be a side effect of SegWit. Raising the limit, even to a miser 2 MB, would have delayed his "stable fee market" by another year or two. And, of course, if he allowed a 2 MB increase, others would soon follow.

Hence his insistence that bigger blocks would force the closure of non-mining relays like Luke's, which (he incorrectly claims) are responsible for the security of the network, And he had to convince everybody that hard forks -- needed to increase the limit -- are more dangerous than plutonium contaminated with ebola.

SegWit is another messy imbroglio that resulted from that pile of lies. The "malleability bug" is a flaw of the protocol that lets a third party make cosmetic changes to a transaction ("malleate" it), as it is on its way to the miners, without changing its actual effect.

The malleability bug (MLB) does not bother anyone at present, actually. Its only serious consequence is that it may break chains of unconfirmed transactions, Say, Alice issues T1 to pay Bob and then immediately issues T2 that spends the return change of T1 to pay Carol. If a hacker (or Bob, or Alice) then malleates T1 to T1m, and gets T1m confirmed instead of T1, then T2 will fail.

However, Alice should not be doing those chained unconfirmed transactions anyway, because T1 could fail to be confirmed for several other reasons -- especially if there is a backlog.

On the other hand, the LN depends on chains of the so-called bidirectional payment channels, and these essentially depend on chained unconfirmed transactions. Thus, given the (false but politically necessary) claim that the LN is ready to be deployed, fixing the MB became a urgent goal for Blockstream.

There is a simple and straightforward fix for the MLB, that would require only a few changes to Core and other blockchain software. That fix would require a simple hard fork, that (like raising the limit) would be a non-event if programmed well in advance of its activation.

But Greg could not allow hard forks, for the above reason. If he allowed a hard fork to fix the MLB, he would lose his best excuse for not raising the limit. Fortunately for him, Pieter Wuille and Luke found a convoluted hack -- SegWit -- that would fix the MLB without any hated hard fork.

Hence Blockstream's desperation to get SegWit deployed and activated. If SegWit passes, the big-blockers will lose a strong argument to do hard forks. If it fails to pass, it would be impossible to stop a hard fork with a real limit increase.

On the other hand, SegWit needed to offer a discount in the fee charged for the signatures ("witnesses"). The purpose of that discount seems to be to convince clients to adopt SegWit (since, being a soft fork, clients are not strictly required to use it). Or maybe the discount was motivated by another of Greg's inventions, Confidential Transactions (CT) -- a mixing service that is supposed to be safer and more opaque than the usual mixers. It seems that CT uses larger signatures, so it would especially benefit from the SegWit discount.

Anyway, because of that discount and of the heuristic that the Core miner uses to fill blocks, it was also necessary to increase the effective block size, by counting signatures as 1/4 of their actual size when checking the 1 MB limit. Given today's typical usage, that change means that about 1.7 MB of transactions will fit in a "1 MB" block. If it wasn't for the above political/technical reasons, I bet that Greg woudl have firmly opposed that 70% increase as well.

If SegWit is an engineering aberration, SegWit2X is much worse. Since it includes an increase in the limit from 1 MB to 2 MB, it will be a hard fork. But if it is going to be a hard fork, there is no justification to use SegWit to fix the MLB: that bug could be fixed by the much simpler method mentioned above.

And, anyway, there is no urgency to fix the MLB -- since the LN has not reached the vaporware stage yet, and has yet to be shown to work at all.

Have you ever heard about Nokia? How did they fail?

Too much internal fanbois and hyped over to such a bias, over the point of no return..

[ComputerGenie]

Because when I want valid, reliable Bitcoin information, the first place I go is  /r/Buttcoin 

[Troll Buster]

URL is irrelevant, it's the content that matters.
The guy also posted a lot of comments in both /r/btc and /r/bitcoin/

Here is another good summary about the block size war history.
He posted this on /r/btc/

https://reddit.com/r/btc/comments/6o872y/behind_on_bitcoin_drama_a_short_history_of_scaling/dkg42ct/

Behind on Bitcoin Drama? A (Short) History of Scaling by Lukovka in btc

[–]jstolfi 1 point 2 days ago*

For some reason ;-) Blockstream's Pravda suddenly felt the need to post the Official Approved History of The Block Size War Scaling. Spin Doctor Peter Rizzo starts off on a good foot with a nice "sidetruth":

>    OCTOBER 8 2014 -- OCTOBER 9, 2014
>
>    SCALING ENTERS THE SPOTLIGHT
>
>    In the face of growing network use, bitcoin developer Gavin Andresen proposes increasing bitcoin's capacity by changing the network's rules.

Sorry Tovarisch, but scaling has been discussed since 2009 by Satoshi and others. It was always been clear that bitcoin would scale well enough to meet the expected demand, and that the 1 MB safety limit should be raised before it affected the operation of the network.

The Block Size War started in February 2013, when Core contributor Gregory Fulton Maxwell (/u/nullc) claimed that Satoshi's design was doomed and the salvation would be to switch to a radical redesign of his own.

Namely, Greg proposed to push all user payments to a completely different "layer 2" network (still to be designed), and restrict bitcoin to a vehicle for high-value "settlements" of the same. The capacity of bitcoin was to be intentionally restricted to be less than the demand, so those "settlement" payments would be forced to pay very high fees by means of a "fee market".

Gavin (the chief bitcoin developer at the time) and Mike Hearn rejected that plan, and insisted that the increase in the block size limit, that has been planned since 2010, was long overdue.

The next slide says

>    DECEMBER 8, 2015 -- DECEMBER 9, 2015
>
>    SEGREGATED WITNESS DEBUTS
>
>    After months of debate, developer Pieter Wuille debuts a scaling proposal called Segregated Witness. Developers are wildly positive about the proposal and its implications for future network growth.

I was in the US when the canonical American view of China, for business expediency, had to change from 1 billion treacherous criminals (as they were depicted, for example, in every other episode of Hawaii Five-O) to 1 billion industrious and friendly guys more huggable than panda bears.

As part of that spin-flipping event, PBS aired a multi-part documentary on the history and culture of China, from a very positive view. I was looking forward to see how they would handle the episode of the Opium Wars -- in which England, with help of French and US warships, invaded China and forced the government to allow the free sale of opium from British India.

But they didn't: between one sentence and the next, without breaking the narrative, the documentary jumped directly from early 19th century to early 20th century, omitting completely any reference to those wars.

Tovarisch Rizzo achieved the same feat there, skipping over the most important event of bitcoin's history since the collapse of MtGox: namely, the creation of Blockstream, their hiring of key Core developers, the defenestration or Gavin and Mike, and the imposition of Greg's two-layer redesign as the new roadmap for the project.

The "reporter" also managed to pack an amazing number of "false truths" in that little text:

>    After months of debate

There had been no public debate or announcement of SegWit before Pieter presented it as the last talk of the last of the two Blockstream-organized Bitcoin Scaling conferences. Rather, SegWit had been developed quietly by Blockstream's employee Pieter and other Blockstream staff/contractors/associates (Greg, Luke, Lombrozo) for months.

>    Pieter Wuille debuts

Not "Pieter Wuille" but "Blockstream". It became obvious that the two "Scaling" conferences were meant to be just a stage for Blockstream to present SegWit, which was just one step of their already-defined roadmap

>    a scaling proposal ... its implications for future network growth.

SegWit has nothing to do with scaling or network growth. It fixes the so-called "malleability bug" which has no impact on the network's capacity.

The proposed implementation of SegWit by Core includes a change in the rules for counting the size of a block, that is expected to be equivalent to a plain increase of the block size limit to 1.7 MB.

(Calling SegWit a "scaling proposal" is ironic given that the first thing that Greg blasted against in that February post was that increasing the block size limit would only "scale" the capacity by a constant factor.)

>    Developers are wildly positive about the proposal

People can judge by themselves whether the reactions to Pieter's talk were "wildly positive".

In fact SegWit is, by far, the most controversial change to the protocol ever. To the point that it led to open death threats against a major miner who is reluctant to accept it...

[ComputerGenie]

URL is irrelevant, it's the content that matters...

It's called sarcasm...

Mainly, I fail to see why it's even a post. For years, Maxwell has

• argued against any sizable increase
• argued that one of the key reasons to keep blocks small is to keep fees high, and
• argued that we should "_decrease_ the [tx] limit below...300k/txn/day level"

I'm not sure why it matters that he still holds the same relative position he's held for so long (or why he matters, even)....

[Troll Buster]

URL is irrelevant, it's the content that matters...

It's called sarcasm...

Mainly, I fail to see why it's even a post. For years, Maxwell has

• argued against any sizable increase
• argued that one of the key reasons to keep blocks small is to keep fees high, and
• argued that we should "_decrease_ the [tx] limit below...300k/txn/day level"

I'm not sure why it matters that he still holds the same relative position he's held for so long (or why he matters, even)....

You forgot the /s tag  
Yeah I know, but it's always fun to toss a truth grenade into a crowd of lying shills.  

[allinvain]

I see that now since BIP91 is locked in, the % of miners signaling has gone down. Interesting.

Yeah.. now it is around 85%. But now the attention seems to have shifted to BIP 141, which is having around 95.1% support now (95.0% support needed to lock in BIP 141). All the blocks seems to be signaling BIP 141 without exception.

Signalling bit 4 AKA BIP91 serves no purpose now that its action is locked in. The important part is enforcing it, meaning rejecting any blocks that don't have bit 1 AKA BIP141 set. On the other hand, bit 4 is meant to be signalled up to the time of the 2x hard fork so pools dropping it now might mean something. More likely it's just shuffling of coin daemon code/settings.

You are right, signalling bit 4 has no point now. I wonder though what you think about Antpool, GBMiners, Kano CKPool and Slush registering as "No!" under the Witness Commitment heading at xbt.eu

[ComputerGenie]

...I wonder though what you think about Antpool, GBMiners, Kano CKPool and Slush registering as "No!" under the Witness Commitment heading at xbt.eu

They didn't "registering as 'No!'".
The site reads

and the site returns

No!

[-ck]

I see that now since BIP91 is locked in, the % of miners signaling has gone down. Interesting.

Yeah.. now it is around 85%. But now the attention seems to have shifted to BIP 141, which is having around 95.1% support now (95.0% support needed to lock in BIP 141). All the blocks seems to be signaling BIP 141 without exception.

Signalling bit 4 AKA BIP91 serves no purpose now that its action is locked in. The important part is enforcing it, meaning rejecting any blocks that don't have bit 1 AKA BIP141 set. On the other hand, bit 4 is meant to be signalled up to the time of the 2x hard fork so pools dropping it now might mean something. More likely it's just shuffling of coin daemon code/settings.

You are right, signalling bit 4 has no point now. I wonder though what you think about Antpool, GBMiners, Kano CKPool and Slush registering as "No!" under the Witness Commitment heading at xbt.eu

Oops I made a mistake in that statement. Bit 4 gets dropped entirely after segwit gets activated and is no longer used. There is no way of knowing who's going to enforce the hard fork component, only their NYA comment gives an indication of intent but isn't used for activation.

As for no commitment, some of those are the vocal pools against segwit. What it means is they're not currently mining blocks that can include segwit transactions. It will be a valid block even once segwit is locked in but won't include any segwit transactions if they do that. It also means less fees for them so I doubt they'll do that indefinitely, though they might happily sacrifice it just on principle. The players involved are certainly that way inclined...

[JayJuanGee]

Yeah I know, but it's always fun to toss a truth grenade into a crowd of lying shills.  

Yeah, right.

For a newbie and your short posting history of nonsense, you surely have established yourself as a credible source for reliable information.

[Meuh6879]

Update : https://www.xbt.eu/ (144 Blocks)