2X

[fragout]

Could someone explain to me how the 2X drama is likely to play out in November?
I know core are against it and some who signed up to the NYA have pulled out but there is still 94% support (signaling) of miners.
Ver and Wu are in the bcash camp or do they want 2x also ?
Whats likly to happen in the weeks/days leading up to the split and wont core need a significant percentage of miners on their side?

[monkeydominicorobin]

Could someone explain to me how the 2X drama is likely to play out in November?
I know core are against it and some who signed up to the NYA have pulled out but there is still 94% support (signaling) of miners.
Ver and Wu are in the bcash camp or do they want 2x also ?
Whats likly to happen in the weeks/days leading up to the split and wont core need a significant percentage of miners on their side?

Since we are speculating. I think 2X is in the rite of passage stage and everyone will adopt it. Eventually. The people who wanted bigger blocks in the Bitcoin Network should rethink their childish fantasies.

[Marlo Stanfield]

Could someone explain to me how the 2X drama is likely to play out in November?
I know core are against it and some who signed up to the NYA have pulled out but there is still 94% support (signaling) of miners.
Ver and Wu are in the bcash camp or do they want 2x also ?
Whats likly to happen in the weeks/days leading up to the split and wont core need a significant percentage of miners on their side?

In the end I doubt miners will go through with it. I think the businesses who signed on were seriously mislead and/or ignorant of what the reality of this proposal actually was. Moving away from Bitcoin Core as the reference implementation just for something as silly as 2x is pretty risky. I highly doubt that's how the agreement was originally presented. Even though it should have been obvious since people who work on Core were either intentionally not invited or just not involved.

[jubalix]

I do not see that core's has any tenable objection to 2X.

[1] Tech has moved on, 2mb is not that big, HD space and bandwidth are much cheaper
[2] BCH has proved you can go bigger blocks and have significant value network, and BCH network has not collapsed.
[3] It provides choice as to on chain or of chain transactions
[4] there is no such thing as spam in the network, but I will use the word "spam" as shorthand for transactions person A does not like.
[5] If you say go 8 times the blocksize and 1/2 the price for fees it will be 4 times more costly to "spam" a block while providing much lower fees. Given there are limited bitcoins, the spammer will run out of BTC to spam.

I welcome any discussion as why I am in error, but as it stand to not 2x then a few years later 4x and so on, seem in bad faith by core. It forces the question cui bono?

[ChromaticStar]

Could someone explain to me how the 2X drama is likely to play out in November?
I know core are against it and some who signed up to the NYA have pulled out but there is still 94% support (signaling) of miners.
Ver and Wu are in the bcash camp or do they want 2x also ?
Whats likly to happen in the weeks/days leading up to the split and wont core need a significant percentage of miners on their side?

According to Coindance, almost all nodes still support Core. btc1 nodes (Segwit2x) have almost no one using it.

https://coin.dance/nodes#allNodes

I was neutral on it until I talked to one of the Core devs about it. I don't understand all the technical explanation, but I'm now firmly against it. I hope Segwit2x fails.

[HeRetiK]

I do not see that core's has any tenable objection to 2X.

[1] Tech has moved on, 2mb is not that big, HD space and bandwidth are much cheaper

2x is a "physical" blocksize increase to 4-6MB, not just 2MB. Regular SegWit already leads to 2-3MB blocks.

[2] BCH has proved you can go bigger blocks and have significant value network, and BCH network has not collapsed.

BCH has barely any blocks that are larger than 50k because there are hardly any transactions being made, so it hasn't proven anything so far.

[3] It provides choice as to on chain or of chain transactions

Regular SegWit does as well.

[4] there is no such thing as spam in the network, but I will use the word "spam" as shorthand for transactions person A does not like.

Spam is defined as transactions that are made explicitely for the purpose of clogging up the network, akin to DDoS requests. While to my knowledge there's little "hard" proof that spam transaction exists, they are not simply "transactions person A does not like."

[5] If you say go 8 times the blocksize and 1/2 the price for fees it will be 4 times more costly to "spam" a block while providing much lower fees. Given there are limited bitcoins, the spammer will run out of BTC to spam.

Agreed.

I welcome any discussion as why I am in error, but as it stand to not 2x then a few years later 4x and so on, seem in bad faith by core. It forces the question cui bono?

Problem being, that this approach would require a hardfork any time a block size increase takes place. While it went fairly OK with BCH, a hardfork is always a risky endeavour.

[doctor-s]

According to Coindance, almost all nodes still support Core. btc1 nodes (Segwit2x) have almost no one using it.

There's a difference between running a node with X software, and supporting the positions of the related development team.

Talking as if running software = support is something that needs to stop. It's not correct.

I run a bitcoin core node but I often do not agree with the decisions made by the core team. There aren't millions of clients to cater to everyone's minute differences of opinion, so it's not exactly easy to 'show' your support in this manner.

[fragout]

Its not the merits of core vs 2x thread. As i said in OP, I am curious as to how this might play out. When will we know how many are "locked in" to either side? Will the fork happen regardless and we wont know until after how many miners support each or is it possible that the fork will not happen due to overwhelming support for either side?

[RustyShackleford1950]

Its not the merits of core vs 2x thread. As i said in OP, I am curious as to how this might play out. When will we know how many are "locked in" to either side? Will the fork happen regardless and we wont know until after how many miners support each or is it possible that the fork will not happen due to overwhelming support for either side?

TBH I don't know and this really requires clarification.

The miners are in opposition to the running nodes at the moment, and the user community is utterly impossible to gauge accurately. Business doesn't seem to care, it will go to whatever is successful.

I believe that ultimate control comes down to miners in the end. If miners mine 2X and nobody mines the legacy, then that's all she wrote.

[jubalix]

I do not see that core's has any tenable objection to 2X.

[1] Tech has moved on, 2mb is not that big, HD space and bandwidth are much cheaper

2x is a "physical" blocksize increase to 4-6MB, not just 2MB. Regular SegWit already leads to 2-3MB blocks.

Thanks just to clarify, when I say 2x, I know segwit gives effective size, but I mean the commitment to make base blocks bigger so we can really make the "spammers" run ou of money and keep on chain fees lower, and give consumer choice.

[2] BCH has proved you can go bigger blocks and have significant value network, and BCH network has not collapsed.

BCH has barely any blocks that are larger than 50k because there are hardly any transactions being made, so it hasn't proven anything so far.

ok....I guess as far as it goes the network has no catastrophically died....I think there have be a few 8mb blocks or something mined, but your right not a real stress test

[3] It provides choice as to on chain or of chain transactions

Regular SegWit does as well.

your right....I should rephrase that that the price for on chain would be less. Also on point what then isentivices miners as block reward drops if they don't have enough transactions on chain?

[4] there is no such thing as spam in the network, but I will use the word "spam" as shorthand for transactions person A does not like.

Spam is defined as transactions that are made explicitely for the purpose of clogging up the network, akin to DDoS requests. While to my knowledge there's little "hard" proof that spam transaction exists, they are not simply "transactions person A does not like."

I don't quite buy that definition. I see a transaction as away to signal to the market. Just because someone wants to send a different signal does not make it less valid, then your transaction. But as I said I will use the moniker "spam" for ease of conversation

[5] If you say go 8 times the blocksize and 1/2 the price for fees it will be 4 times more costly to "spam" a block while providing much lower fees. Given there are limited bitcoins, the spammer will run out of BTC to spam.

Agreed.

Yeah I see this as a way of quickly running spammers out of funds, by allowing more people to signal and so get information to the market.

I welcome any discussion as why I am in error, but as it stand to not 2x then a few years later 4x and so on, seem in bad faith by core. It forces the question cui bono?

Problem being, that this approach would require a hardfork any time a block size increase takes place. While it went fairly OK with BCH, a hardfork is always a risky endeavour.

Your right hardforks have risks, I "feel" though that not hard forking can have risks of stultification. I wonder if some sort of dynamic scaling would allay your hard for concerns.

Thanks for your considered opinions by the way. I like it when you address point by point.

 

[HeRetiK]

Its not the merits of core vs 2x thread. As i said in OP, I am curious as to how this might play out. When will we know how many are "locked in" to either side? Will the fork happen regardless and we wont know until after how many miners support each or is it possible that the fork will not happen due to overwhelming support for either side?

As long as there are miners supporting either side a hardfork is inevitable and will occur as soon as the first SegWit block will be mined that is to large for core. Which side will see more long-term support and thus have more mining power is anyone's guess.

[...]

Your right hardforks have risks, I "feel" though that not hard forking can have risks of stultification. I wonder if some sort of dynamic scaling would allay your hard for concerns.

Thanks for your considered opinions by the way. I like it when you address point by point.

To be honest, after the BCH split of I see hardforks as having merits of their own. Given that there is a proper 2-way replay protection. Dynamic scaling leads to yet a different set of challenges, but I didn't follow that discourse too deeply.

[ChromaticStar]

According to Coindance, almost all nodes still support Core. btc1 nodes (Segwit2x) have almost no one using it.

There's a difference between running a node with X software, and supporting the positions of the related development team.

Talking as if running software = support is something that needs to stop. It's not correct.

I run a bitcoin core node but I often do not agree with the decisions made by the core team. There aren't millions of clients to cater to everyone's minute differences of opinion, so it's not exactly easy to 'show' your support in this manner.

I realize that not everyone is going to support every decision Core makes, but I would assume if someone supports Segwit2x they would at least be running the btc1 client. What is the rationale for not running a btc1 node if they have the intention of hardforking off the Core chain in November?

[ScripterRon]

What is important to me is what software will be used by the companies that I do business with.  If they use Bitcoin Core, then I must continue to use Bitcoin Core.  If they switch to BTC1, then I'll need to switch as well.  The worst case would be they are split between the two chains.

BitcoinABC included replay protection so you could use either chain (although you still needed to install software for both chains).  But BTC1 has said they will not include replay protection, so this leads to transactions being accepted on both chains.  I understand why BTC1 does not want replay protection: it would require new wallets for everybody to use the BTC1 chain.

[achow101]

2x is a "physical" blocksize increase to 4-6MB, not just 2MB. Regular SegWit already leads to 2-3MB blocks.

Thanks just to clarify, when I say 2x, I know segwit gives effective size, but I mean the commitment to make base blocks bigger so we can really make the "spammers" run ou of money and keep on chain fees lower, and give consumer choice.

With 2x, the worst case size is ~8 MB. We don't know how such large blocks will effect the network. It could increase orphan rates, it could cause many nodes to drop off of the network because they can't handle the additional load. We don't know if the network can handle such larger blocks. Just because your internet connection can and your machine can handle the load does not mean that everyone around the world who is running the node can. They may be restricted by things like the Great Firewall of China which may find larger blocks easier to spot and thus make Bitcoin easier for them to block entirely.

Furthermore larger blocks can lead to miner behavior that is detrimental to the network. If the mempool is constantly cleared by a new block, then miners may be more incentivized to perform fee sniping instead of moving the blockchain forward. That is not good for the network.

Why does the "base block size" need to be bigger to stop spammers? You don't think they aren't going to also use segwit? Spammers can use segwit and pay less in fees than they would with a non-segwit transactions, and make more spam that fits in a block. If you double the maximum block weight, you depress fees even more and let spammers pay even less to spam transactions.

Also on point what then isentivices miners as block reward drops if they don't have enough transactions on chain?

Having more transactions on chain does not necessarily correspond to having more transaction fees in a block. If the general idea is that larger blocks will decrease fees, then that means that more transactions need to be made at a lower fee rate in order for total transaction fees to match the fees for when blocks were smaller. Currently transaction fees are pretty low anyways except the times when people are spamming transactions (and it is very noticeable when that happens because the number of transactions in the mempool at a certain fee rate inorganically shoots up).

[AtheistAKASaneBrain]

Could someone explain to me how the 2X drama is likely to play out in November?
I know core are against it and some who signed up to the NYA have pulled out but there is still 94% support (signaling) of miners.
Ver and Wu are in the bcash camp or do they want 2x also ?
Whats likly to happen in the weeks/days leading up to the split and wont core need a significant percentage of miners on their side?

https://coin.dance/blocks

Here is the ultimate proof that the current 94% signaling is nonsense. Look at the current miners signaling for segwit2x and you will find F2pool. Well here is the actual stance of FP2pool with segwit2x:

https://twitter.com/f2pool_wangchun/status/906022864389681153

So basically he hasn't stopped signaling because he is too lazy to do the whole reset thing, but once the time arrives, he will not send hashrate to scam2x even if it currently shows up on that list.

So stop thinking 94% of hashrate will signal for it.

[aleksej996]

I guess that the increase in block size in not that necessary right now compared to the associated risks. Bitcoin Core probably sees Bitcoin as a stable network, that doesn't compete with altcoins in the speed of technological development as much as in stability and security in which Bitcoin can and is winning.

Fees sometimes still rise, but neither Lightning Networks nor even segwit has reached high adoption. Bitcoin network is ready for it, but the technology is still in the development/testing stage. We can't know at this point if an increase in block size is needed and is it needed right now, while the S2X has no replay protection and appears to be rushing this fork as a consequence. LN nor Segwit can't be considered a failure at the time of the fork, as it is too early and we don't have as much of a need for it to rush it.

[gmaxwell]

speed of technological development

We do in terms of _real_ technological development, but not fake marketing crap... and not at the expense of stability and security.

Compare, Bitcoin moving to innovative second generation error protected addresses w/ BIP173  vs  ethereum still behind bitcoin 0.1 without a strong safe to use address system.

Or ethereum validation being so slow that its impractical to sync-up a full node anymore, pushing almost all eth users onto SPV-like security for their initial sync, while Bitcoin sync tx/s speed is orders of magnitude faster and keeps getting faster.

[aleksej996]

speed of technological development

We do in terms of _real_ technological development, but not fake marketing crap... and not at the expense of stability and security.

Compare, Bitcoin moving to innovative second generation error protected addresses w/ BIP173  vs  ethereum still behind bitcoin 0.1 without a strong safe to use address system.

Or ethereum validation being so slow that its impractical to sync-up a full node anymore, pushing almost all eth users onto SPV-like security for their initial sync, while Bitcoin sync tx/s speed is orders of magnitude faster and keeps getting faster.

Omg, the famous Gregory Maxwell responded to my post What an honor!

I agree. They don't even have a good multisig, if you search for an ethereum multisig all you get is bunch of news about lost coins due to the vulnerability in the commonly used multisig contract.

The inability to sync an ethereum node is exactly why I never used it in the first place. I tried, but it got so slow that it would never sync at that rate, perhaps due to some buggy code.

I appreciate your work mr. Maxwell. Thank you for all the good work you have done!

[BitUsher]

I do not see that core's has any tenable objection to 2X.

99% of devs oppose segwit2x and will never work on btc1

[1] Tech has moved on, 2mb is not that big, HD space and bandwidth are much cheaper

2MB is the average capacity alloted with segwit alone with 90+% segwit txs and 4MB peak. segwit2x doubles this with 4MB average and 8MB peak.
Yes this is far to much and reckless to HF to since we have yet to study the effects of segwit alone which is a massive blocksize limit increase.

[2] BCH has proved you can go bigger blocks and have significant value network, and BCH network has not collapsed.

Most of BCH blocks are completely empty , and that chain is highly centralized.

seem in bad faith by core.

I could care less if 100% core devs supported segwit2x . The only thing that would happen if they pulled a 180 is I would lose respect for them and not follow them with their alt.

[doctor-s]

According to Coindance, almost all nodes still support Core. btc1 nodes (Segwit2x) have almost no one using it.

There's a difference between running a node with X software, and supporting the positions of the related development team.

Talking as if running software = support is something that needs to stop. It's not correct.

I run a bitcoin core node but I often do not agree with the decisions made by the core team. There aren't millions of clients to cater to everyone's minute differences of opinion, so it's not exactly easy to 'show' your support in this manner.

I realize that not everyone is going to support every decision Core makes, but I would assume if someone supports Segwit2x they would at least be running the btc1 client. What is the rationale for not running a btc1 node if they have the intention of hardforking off the Core chain in November?

In a word: Inertia.

It's very easy for node operators to be lazy, myself included. You set and forget, and you don't care that much. It's on a server you don't use or log into very often, or it may be a remote server that you rarely look at, etc.

IMO this is a huge roadblock to progress with the bitcoin protocal, but it may be a benefit to network security...

So some good, some bad.

I dislike this inertia effect because it consolidates control and encourages extremely conservative behaviour. The conservative base further increases control as time goes on, regardless of whether that's the best course of action or not.

The more decisions that I disagree with, the more I feel pressured to act. Previously, I've been lazy and not bothered, but I think I might do a client changeover tonight.