Just confriming, segwit or segwit2x is going ahead on BTC?

[Casimir1904]

If 90% or more of the miners supports it then its really core who should add replay protection and change the difficulty adjusting.
Without adjusting the difficulty and without replay protection its most likely that the market will adopt quick on segwit2x.
The mining support could even drop then ( not must ).
It would be in own interest of core to add replay protection and update the difficulty adjusting.
If most miners will not support segwit2x by the time it activates then thats ofc another story.
I prepare for all outcomes but if segwit2x becomes the chain with most hashpower then I'll see that as Bitcoin as probably the 1mb chain will die if no replay protection and quicker difficulty adjusting is added.

Splitting your own coins can be easly done with RBF.
Send with low fee on the majority chain and when its confirmed use RBF to send them with higher fee on the minority chain.

[1715045226]

1715045226

[severaldetails]

So I have read in a few articles now that F2Pool will not support segwit2x anymore.
That would mean about 10% of the mining power just left the proposal.
According to the article it is probable that other mining pools and businesses will withdraw their consent to segwit2x as well.
How will that affect segwit2x?

[gentlemand]

How will that affect segwit2x?

The one and only thing it had going for it was that overwhelming 'consensus'. That will rapidly dwindle away. What you're left with is a rushed hard fork with no rated developers that no one wants other than a minuscule handful of people.

It's not going to happen in any meaningful way.

If 90% or more of the miners supports it then its really core who should add replay protection and change the difficulty adjusting.

Why should every single user out there have to migrate to something decided by a handful of people with blinking boxes?

[DooMAD]

So I have read in a few articles now that F2Pool will not support segwit2x anymore.
That would mean about 10% of the mining power just left the proposal.
According to the article it is probable that other mining pools and businesses will withdraw their consent to segwit2x as well.
How will that affect segwit2x?

It's strange because the recently mined F2Pool blocks I could be bothered to check were still putting NYA in their coinbase and the declared Segwit2x support hasn't dropped yet.  If there is a drop in support, it increases the likelihood of either a permanent split, or if the situation snowballs and drops completely, then the fork might be aborted.  

[BeastLee]

I have not heard that F2 pool left the 2x proposal, that's great, the more the merrier. Can't wait to sell more hard forked useless alt coin. I am honestly more worried about an alt coin overcoming bitcoin, than this 2x hard fork.

[Casimir1904]

I support bigger blocks. Bitcoin becomes less usable without.
Segwit didn't solve anything so far.
Adoption is very slow and many was ready for years.
I've integrated segwit to our plattform and its mostly done but no one uses segwit so far.
Core wallet doesn't even support it fully.
The change goes straight to a non segwit address, you would assume they would've code something in to enable segwit fully once its activated on the chain.
LN is far from ready and probably will face a lot of problems what might be solved or not.
Bigger blocks much earlier would've make sense and the blocks would've been smaller automatic again once other solutions are ready and adopted.
For now I see those scenarios:
1. Segwit2x become the majority and the 1MB chain will die if no changes made to diff adjusting and no replay protection added.
2. 1MB stays the majority chain and Bitcoin Cash will get more support as the 1MB chain becomes less usable with full blocks and high fees.
3. Segwit2x and 1MB becomes both enough hashpower to survive in this case it would be open what chain will win in the end.

F2pool said they will not support NYA anymore but still signaling. In the end individual miners decide on what pool they mine.
If many miners would disagree with NYA they would already have switched to slush or made new pools.
Till November a lot could change. It will be interesting but is annoying the same time.
The stalling caused a lot damage to Bitcoin already even if the price is high now what could be a bubble as well or not or maybe the price would've been even higher.

There is no technical and no economical reason to not increase the blocksize now and work on other solutions the same time.
Bitcoin Cash was released in a rush and more wallets and services support it already than Segwit and Segwit was ready for years...
Blocksize increasing would require to update nodes, such splits cost a lot more time and work to do.

Oh and the argument that bigger than 1MB blocks would not allow someone to run full nodes becomes annoying also.
With segwit the blocksize could be 4MB and the amount of transactions fitting in a block would only double if all would use segwit.

[Carlton Banks]

Oh and the argument that bigger than 1MB blocks would not allow someone to run full nodes becomes annoying also.
With segwit the blocksize could be 4MB and the amount of transactions fitting in a block would only double if all would use segwit.

So, which contradictory "fact" of yours would you prefer to be true?

• Bitcoin (with Segwit) has 1MB blocks
• Bitcoin (with Segwit) has 4MB blocks
• 2MB blocks is not enough
• 2MB blocks will be enough
• Stating that >1MB blocks is unsustainable is annoying

(bolded are true, red is subjectively true )


More to the point, no blocksize will ever be enough. That's why trying to use "scalability" arguments to justify blocksize increases is never going to make sense, it's an inherently un-scalable technology.

Scalability cannot happen on the blockchain, but it can happen at the level of transaction scripting. Which is, ironically, a point that the NYA proposal concedes anyway. Makes one wonder why the NYA puts so much emphasis on a blocksize increase... (and taking control of the Bitcoin source code in order to hard fork to that increased blocksize...)

[Casimir1904]

How would they control the code if Core devs would follow the 2MB increase?
We're far away from not being able to scale on chain and increasing the blocksize doesn't mean there can't be developed on other scaling solutions.
If other solutions works and get adopted then the blocksize keeps smaller or gets smaller again.

But its simple. If majority mines the segwit2x chain then core gave the main coding away.
Nothing stops them from following that chain.

[jubalix]

what would happen if BCH activated segwit....? just to in your face segwit.....2x and also take the market

I mean what advantage or argument would you have left not to use BCH with segwit......

[DooMAD]

what would happen if BCH activated segwit....? just to in your face segwit.....2x and also take the market

Seems pretty unlikely, heh.  BCH supporters made a pretty huge song and dance about how SegWit supposedly wasn't part of Satoshi's vision and isn't "true" to Bitcoin, so there'd be an inordinate quantity of humble pie to swallow if they went down that route.  It's too much of a marketing U-turn to take it seriously.  It could potentially even cause a loss of some of that existing support.  Those who do genuinely oppose SegWit could abandon it and look elsewhere.  Plus I'm not convinced BCH would take the market considering the fairly divisive manner in which it suddenly appeared out of nowhere.  I think most people have made up their minds about BCH by this point and probably won't be convinced otherwise.

How would they control the code if Core devs would follow the 2MB increase?

Some people around here have some pretty interesting ideas about "control" in Bitcoin and mistakenly believe that only one single group of developers are allowed to make decisions and that miners are somehow a subservient underclass who do the bidding of the devs and can't decide anything for themselves.  Time and again they'll claim it's an attempt to take control from that group of developers, but then they can't seem to square this belief with the undeniable fact that anyone can edit the code and run any code they like, which means those developers never had control to begin with.  I would say they're safe to ignore because their views are so logically flawed, but the sad thing is, people are sometimes taken in by this ridiculous view and start repeating their rhetoric about "hostile takeovers", so you should continue to confront them wherever you find them.  Everyone does what they think is best for themselves because that's how this thing was designed to work.  It never has been and never will be about preserving the power of some centralised group of coders, because they don't (and shouldn't) have all the power.  No one dictates anything.  Not developers, not miners, not users.  It's only Bitcoin when all three come together voluntarily because incentives are aligned.  

[gentlemand]

what would happen if BCH activated segwit....? just to in your face segwit.....2x and also take the market

I mean what advantage or argument would you have left not to use BCH with segwit......

Because at one point it was 97% mined by a mystery miner. Following that the inflation rate was controlled by when one miner could be bothered to wake up or not. The EDA may have been necessary but it was also clearly not expected to be gamed so brutally.

Why would anyone follow a coin with developers so dim and miners so dominant? What else will they forget to address or break in the future? They've set a mediocre precedent. Lots of people have a grudge against Core but they still follow their code because they know what's what.

[Casimir1904]

what would happen if BCH activated segwit....? just to in your face segwit.....2x and also take the market

I mean what advantage or argument would you have left not to use BCH with segwit......

More likely they would integrate Flextrans instead of Segwit.

[AlexGR]

what would happen if BCH activated segwit....? just to in your face segwit.....2x and also take the market

I mean what advantage or argument would you have left not to use BCH with segwit......

Because at one point it was 97% mined by a mystery miner. Following that the inflation rate was controlled by when one miner could be bothered to wake up or not. The EDA may have been necessary but it was also clearly not expected to be gamed so brutally.

I think people with experience in altcoin mining, actually expected it - because they've seen it happen.

He was right, though.  The fact that BCH has fast difficulty adjustment and bitcoin doesn't while the Chinese control most of the hash power is gonna be mega-problems for BTC.

A fast difficulty adjustment works both ways. Say a lot of SHA256 power goes into bch...it rapes mining for a few tens of blocks with low diff and then miners switch back to Bitcoin, while bch hangs there, waiting for miners, but nobody is mining it due to high difficulty. It'll take hours to get it unstuck.

The effect on bitcoin is a few delayed blocks, while the fast-adjusting bch will have created an anomaly similar to how multi-pools rape altcoins - while getting raped itself and then left for hours to come down. The altcoin market has shown that the fast-adjusting coin is more exploitable and disrupted from multi-pools.

The problem cannot be easily solved for bch because if you try a detection mechanism that checks whether the blocks aren't arriving to do a massive diff cut, then you are going into an uneven mining pattern, accelerating inflation.

[jubalix]

[snip]><[snip]

BCH has shown that a 8MB block is feasible....if nothing else....

No, it really hasn't.

How is that would you care to elaborate?

by I suppose a crude metric, BCH has a network running and it's market cap is circa $7B

[DooMAD]

[snip]><[snip]

BCH has shown that a 8MB block is feasible....if nothing else....

No, it really hasn't.

How is that would you care to elaborate?

by I suppose a crude metric, BCH has a network running and it's market cap is circa $7B

As someone trying to be as impartial as possible in all this, the assertion may be that BCH isn't actually using all that extra capacity it boasts.  In the last 500 blocks, there hasn't been a single block over 150kb, let alone anything like exceeding the legacy 1mb cap.  It's not a true test of how the network would cope with larger blocks if they're generally far smaller on average than the ones being used in Bitcoin at the moment.  BCH just isn't seeing the usage right now to demonstrate what purpose it set out to perform.  It's not proving anything about larger blocks until the blocks are actually larger.

[gmaxwell]

what would happen if BCH activated segwit....? just to in your face segwit.....2x and also take the market

Seems pretty unlikely, heh.  BCH supporters made a pretty huge song and dance about how SegWit supposedly wasn't part of Satoshi's vision and isn't "true" to Bitcoin, so there'd be an inordinate quantity of humble pie to swallow if they went down that route.  It's too much of a marketing U-turn to take it seriously.

BCH already incorporates part of segwit-- BIP143, the segwit signature scheme they've just renamed it "safesigs" and present it like it's their own brilliant invention. They're working on merging BIP173 (the error protected base32 addresses we created) but renaming it "cashaddress"... Sense a pattern here?

They've been going on about 'flextrans' which contains exactly the same design feature about segwit that they've thrown so much "not Satoshi's vision" mud about-- that new transactions don't commit to past signatures (a necessary criteria for fixing malleability).

They've gone on about "schnorr signatures" but their implementation there is just our prior abandoned code with the copyright headings removed and their own names added.

Don't make the mistake that honesty or technical merit are even considerations in their marketing. For all it matters for their marketing there is no u-turn so long as they don't admit it.  If you can tell that they are full of crap you aren't in the bcash target audience.

Now the interesting point is that 2Xcoin is going after the same unsophisticated audience, splitting that market.

[Carlton Banks]

Hmm, so it appears the technical specifications of Bitcoin Cash and Segwit2x are going to be very similar by the time the planned hard fork is set to happen. I've always liked Bitcoin Cash, lol (if only for making alt-dev hard forks look ridiculous )

[nibor]

actually "few %" should be "about 10%". I did not realise that Bitcoin Unlimited and Classic are both compatible with the change. Not sure about XT - but only 27 nodes.

https://coin.dance/nodes is a bit clearer..

There are 8124 nodes (I excluded the Bitcoin-ABC as they are now an alt-coin!)

And if I sum BitcoinUnlimited, btc1 and Bitcoin Classic I get 977 - so 12%.

Still a lot less than 100%!! Will be interesting to see how this changes over the next 100 days...

Update - 8404 nodes. 940 segwit2x. - so down to 11%.

So Core has 90% nodes and Segwit2x 90% miners. Oh dear!

[AtraxPool]

actually "few %" should be "about 10%". I did not realise that Bitcoin Unlimited and Classic are both compatible with the change. Not sure about XT - but only 27 nodes.

https://coin.dance/nodes is a bit clearer..

There are 8124 nodes (I excluded the Bitcoin-ABC as they are now an alt-coin!)

And if I sum BitcoinUnlimited, btc1 and Bitcoin Classic I get 977 - so 12%.

Still a lot less than 100%!! Will be interesting to see how this changes over the next 100 days...

Update - 8404 nodes. 940 segwit2x. - so down to 11%.

So Core has 90% nodes and Segwit2x 90% miners. Oh dear!

Oh dear. What a perfect way to sum it all up..

Not to mention...

Code:

Block Size Vote 	Blocks 	%
  default 	100 	65.79%
  BU 	51 	33.55%
  segwit 	1 	0.66%
Block Versions 	Blocks 	%
  v4 	152 	100.00%

https://www.blocktrail.com/BTC

[sickpig]

Hmm, so it appears the technical specifications of Bitcoin Cash and Segwit2x are going to be very similar by the time the planned hard fork is set to happen. I've always liked Bitcoin Cash, lol (if only for making alt-dev hard forks look ridiculous )

Maxwell's way of deceiving things is pretty unique I have to say.

Key parts of SegWit are:

- surprise, surprise witness segregation: i.e. moving scripts and signatures to a separate data structure from the one used to store data used to determine transaction effects.

- implement the above in a way that is soft-fork deployable, quoting the relevant part BIP 141: "The witness is committed in a tree that is nested into the block's existing merkle root via the coinbase transaction for the purpose of making this BIP soft fork compatible."

- changing bitcoin's economic incentive structure that will determine txns inclusion in a block via the introduction of a 75% discount applied to the witness part of a transactions, i.e. base size * 3 + total size  <= 4MB

All of the above will not be integrated in any of Bitcoin Cash implementations in the near, mid, long term or possibly never, for two order of reasons:

- bitcoin cash don't need witness segregation to increase the block size cause the block size limit has been removed all together on August 1st.

- the use a single composite constraint (weight) and the arbitrary discount of the witness data increase the complexity of bitcoin's economic incentives (two economics good rather than one) in a way that is not being studied and analyze enough.
 
The rest of the specification (BIP142/173, BIP143, BIP144, BIP145) are just an adaptation of various part of the code base to accomodate the new nested tree where witness is stored (e.g. BIP 145 adaptation of getblocktemplate), or "independent" piece code that have a reason to be used that goes beyond SegWit (the new signature scheme defined in BIP 143 or the the new base32 encoding of bitcoin address). 

In fact base32 encoding has been used already in project like TOR and I2P.

Lastly, Maxwell's allusions to the mis appropriation and rebranding of core ideas are at best delusional.

These are the two commits that implements the new signature scheme described in BIP 143 in Bitcoin ABC:
 
db236b5a6e2f6cf67d194f86f178584fa99b3ca7
1f50d97ef1885bdb09ea5ae403385fac23bf7276

as you can see both mention BIP 143 as the original specification. BIP 143 is mentioned in the original bitcoin cash specification, and of course 'sigsafes' label has never being used, I wonder where Maxwell found it. Same applies to Bitcoin Cash BIP 173 implementation.