POLL: Should people not use BIP148, are BIP91 miners lying, and a 3 way fork!

[Mad7Scientist]

With over 80% going with BIP91 (signalling bit 4) it looks like SegWit2x is going to be the next thing, unless those nodes are lying and are just signaling bit 4 but aren't really SegWit2x.

With the 336 block grace period after SegWit2x activates but before SegWit activates on the SegWit2x network, BIP148 can still activate since SigWit isn't activated yet creating possibly another fork. So it could be forked between BIP148 and SegWit2x. If both BIP148 and SegWit2x are forked but classic nodes still have more hashing power than either of those, then the classic node will have the longest chain with BIP148 and SegWit2x having their own forks (neither of which will accept blocks from classic miner nodes).

So if SegWit2x is a clear winner, running BIP148 will just create another possibly fork and eventually lose, assuming BIP91 nodes aren't lying. So should people not use BIP148?

My big question here is why do some people think that BIP91 (SegWit2x) nodes are lying and aren't really SegWit2x? What do they have to gain by doing this? Don't they want SegWit(2x) to have more overall transactions and more total fees?

[unamis76]

With over 80% going with BIP91 (signalling bit 4) it looks like SegWit2x is going to be the next thing, unless those nodes are lying and are just signaling bit 4 but aren't really SegWit2x.

With the 336 block grace period after SegWit2x activates but before SegWit activates on the SegWit2x network, BIP148 can still activate since SigWit isn't activated yet creating possibly another fork. So it could be forked between BIP148 and SegWit2x. If both BIP148 and SegWit2x are forked but classic nodes still have more hashing power than either of those, then the classic node will have the longest chain with BIP148 and SegWit2x having their own forks (neither of which will accept blocks from classic miner nodes).

So if SegWit2x is a clear winner, running BIP148 will just create another possibly fork and eventually lose, assuming BIP91 nodes aren't lying. So should people not use BIP148?

If we go BIP91, we won't go SegWit2x... It's strange because many nodes are signaling support for both. Some are most likely lying.

People should use what they think that will make Bitcoin go forward, regardless of "color" and "clubistic preference"...

My big question here is why do some people think that BIP91 (SegWit2x) nodes are lying and aren't really SegWit2x? What do they have to gain by doing this? Don't they want SegWit(2x) to have more overall transactions and more total fees?

They're lying because they're one thing or another... If they choose both, they must still favor one of them. I think what's happening is that miners are really tired of this stalemate and are desperately looking for ways to scale regardless of what they really want. This will definitely end the stalemate faster, the question is, at what cost?

And yes, the main goal for them is having more transacting space in the network in order to collect more fees, while keeping the cost of transacting low. This is a win-win situation for users and miners, which some people on the forums in the last few months don't really seem to grasp/realize.

[Lutpin]

If we go BIP91, we won't go SegWit2x... It's strange because many nodes are signaling support for both. Some are most likely lying.

BTC1 (the SegWit2X client) [1] merged BIP91. Those two don't oppose each other.

The New York Agreement, also referred to as the “Silbert Accord” or “SegWit2x,” plans to activate SegWit through BIP91. Like BIP148, all BIP91 nodes would reject any blocks that do not signal readiness for BIP141. But unlike BIP148, BIP91 nodes would only do this once 80 percent of hash power signals that they support BIP91, within a period about two days. This should also minimize the chance of a split.

Coindesk regarding BIP91:

Segwit2x was introduced during CoinDesk's Consensus 2017 conference in May. Based on a fork of the Bitcoin Core software client called BTC1, Segwit2x seeks to both implement SegWit and raise the block size limit.
About a month later, in response to that, Bitmain Warranty engineer James Hilliard introduced BIP 91 as a way to implement SegWit quickly and safely, without the risk of splitting the network.

[1] https://github.com/btc1/bitcoin

My big question here is why do some people think that BIP91 (SegWit2x) nodes are lying and aren't really SegWit2x?

They're lying because they're one thing or another... If they choose both, they must still favor one of them.

They're not. A miner running BTC1 is supporting SegWit2X and BIP91.

[maku]

Miners kept their word and started signalling SegWit through BIP 91 and we have overwhelming victory -
CoinDance states that: BIP 91 has locked in with 93.1% and BIP 91 activation is scheduled to take place in: 349 blocks
I can't imagine a better outcome than this. Just look at the price of Bitcoin, it is recovered and soon we will reach new ATH.

[vanluan]

Are most BIP91 signals true ?
The BIP91 signals are generally legit, we'll get SegWit2x.  
SegWit2x = Step1: Segwit + Step2: increasing the network's block size to 2MB...
Step 1 - finish
Step 2 - fail

[hatshepsut93]

I'll add one more question to this topic: if it will turn out that miners were for some reason lying when they signaled SegWit and it won't get activated in upcoming weeks, will this cause a chain split due to UASF nodes rejecting their blocks (even past August 1st)?

[BTCLovingDude]

Are most BIP91 signals true or are they from lying nodes?

the signals were the block versions, you can't fake that! and nodes have nothing to do in this stage. all these versions are written down and saved on the blockchain (chain of these blocks with their versions). you can check it if you want yourself. so there is no lying about it.

what people are pointing out is the fact that the fork has not yet happened for real, this was just miners officially saying "we are ready and accepting SegWit through BIP91" and unless it is finalized, they can back down.
but "can" does not mean "will" back down.

[hv_]

Miners kept their word and started signalling SegWit through BIP 91 and we have overwhelming victory -
CoinDance states that: BIP 91 has locked in with 93.1% and BIP 91 activation is scheduled to take place in: 349 blocks
I can't imagine a better outcome than this. Just look at the price of Bitcoin, it is recovered and soon we will reach new ATH.

... and the bloodbath might be even worse once this is about to be broken from any side ....

[Mad7Scientist]

I'll add one more question to this topic: if it will turn out that miners were for some reason lying when they signaled SegWit and it won't get activated in upcoming weeks, will this cause a chain split due to UASF nodes rejecting their blocks (even past August 1st)?

Do you mean SegWIt2x? I assume if that locks in but it turns out that miners were lying then SegWit2x would fork their own chain but they wouldn't necessarily have the majority of hash power due to the lying, so yes that would cause a fork with classic nodes mining the longer chain. Add BIP148 activating as well during this time and if that has a shorter chain too then it's a 3 way fork.

[unamis76]

If we go BIP91, we won't go SegWit2x... It's strange because many nodes are signaling support for both. Some are most likely lying.

BTC1 (the SegWit2X client) [1] merged BIP91. Those two don't oppose each other.

The New York Agreement, also referred to as the “Silbert Accord” or “SegWit2x,” plans to activate SegWit through BIP91. Like BIP148, all BIP91 nodes would reject any blocks that do not signal readiness for BIP141. But unlike BIP148, BIP91 nodes would only do this once 80 percent of hash power signals that they support BIP91, within a period about two days. This should also minimize the chance of a split.

Coindesk regarding BIP91:

Segwit2x was introduced during CoinDesk's Consensus 2017 conference in May. Based on a fork of the Bitcoin Core software client called BTC1, Segwit2x seeks to both implement SegWit and raise the block size limit.
About a month later, in response to that, Bitmain Warranty engineer James Hilliard introduced BIP 91 as a way to implement SegWit quickly and safely, without the risk of splitting the network.

[1] https://github.com/btc1/bitcoin

My big question here is why do some people think that BIP91 (SegWit2x) nodes are lying and aren't really SegWit2x?

They're lying because they're one thing or another... If they choose both, they must still favor one of them.

They're not. A miner running BTC1 is supporting SegWit2X and BIP91.

Thank you for your detailed post. Supporting BIP91 still doesn't mean you support SegWit2x. I have read BIP91 and I did not see any reference to a block size increase there. Activating BIP91 isn't a guarantee (not even a promise or a compromise) for a block size increase.

In the end, although these do not oppose each other, both work towards different goals.

All that being said, why is the support list for BIP91 different from the support list for SegWit2x?

[Lutpin]

Supporting BIP91 still doesn't mean you support SegWit2x.

You don't have to support both BIP91 and SegWit2X, but you can support both (and every supporter of sw2x currently also supports bip91).

I have read BIP91 and I did not see any reference to a block size increase there.

BIP91 is a mean to an end. It was coded after it became evident that SegWit2x (NYA / bit 4) won't be compatible with BIP141 SegWit ( bit 1).

Activating BIP91 isn't a guarantee (not even a promise or a compromise) for a block size increase.

That's not the point of BIP91 and nobody said it would be.

In the end, although these do not oppose each other, both work towards different goals.

The goal of BIP91 is to activate SegWit, the goal of SegWit2x is to activate SegWit (and fork to 2MB later).
I do not see where both have different goals looking on a short scale.


97% of those "lying" miners are currently mining blocks that signal for BIP141 SegWit.

[izza123]

https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki


the notes for BIP141, which BIP91 is made to activate, state that there will be a block size increase, wouldnt that technically mean
support for BIP91 means support for BIP141 which implies support for a block size increase? If im confused let me know

[pizamoi]

https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki


the notes for BIP141, which BIP91 is made to activate, state that there will be a block size increase, wouldnt that technically mean
support for BIP91 means support for BIP141 which implies support for a block size increase? If im confused let me know

Segwit is the equivalent of a block size increase as it allows more transactions per block. I think this is what they mean when they say block size increase.

[Lutpin]

https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki
the notes for BIP141, which BIP91 is made to activate, state that there will be a block size increase, wouldnt that technically mean
support for BIP91 means support for BIP141 which implies support for a block size increase? If im confused let me know

Segwit is the equivalent of a block size increase as it allows more transactions per block. I think this is what they mean when they say block size increase.

Block size is replaced with block weight.
That's not the same as a straight increase from 1MB blocks to 2MB blocks, which is planned as second part of SegWit2x.
BIP141 does not specify anything in that regard, it's the SegWit soft-fork, no 2MB hard-fork.


With BIP91 enforcing since block 477,120 all following blocks have signaled SegWit/BIP141, are we still worried about miner lying?

[Mad7Scientist]

Segwit is the equivalent of a block size increase as it allows more transactions per block. I think this is what they mean when they say block size increase.

If I understand correctly SegWit is a soft fork which takes advantage of how wallets just need to display amounts and don't need as much data in a block as those who are mining. So only mining nodes need SegWit support and the SegWit data is stored along side the regular block data which had transaction signatures removed and moved to the separate storage to make more room in the 1MB blocks. The SegWit data isn't sent to non SegWit nodes of course.

As far as I know there is no compatibility problem with the continued use of non SegWit capable clients.