Topic: [2017-07-02] Bitcoin Core Dev: SegWit2x Will Fail, Its Goal Is to Stall SegWit (Read 1166 times)

That's a chart showing a slow increase in the number of confirmed transactions, consistent with a rise in spam transactions and a recent fall-off.



Sorry if my words were harsh. The mempool unconfirmed transactions (https://blockchain.info/charts/mempool-size?timespan=60days) is what had a 5-fold reduction. And that is due to a reduction in spam. The spam transactions were often completely invalid, but time-consuming to invalidate - specially crafted packages to deliberately jam up validating nodes and miners.

Obviously I meant this. What were we talking about?  


5-fold? According to the numbers I analyzed (see the link above), the number of confirmed transactions decreased from a peak of 290K/day to 200K/day. In 2016, there was a similar movement in the same period (from a peak of 210K/day to 170K/day).

And no, I have never said that there was _no_ spam, only that there is an explanation for a large part of the decline, and it's  not _only_ the holiday season.

Do you mean this "growth of 40% per year"? LOL, cliff-diving:



You must be joking. No one could be this stupid. Of course it was spam, the transaction volume didn't just magically decrease 5-fold "because of the holiday season in the North Hemisphere" LOL.

It depends what you mean by "fall".


the fundamental points being: fall when? And why?


If the price rises in one blockchain fork quickly after either BIP148 forking or Segwit2x forking, then where's the fiat coming from to cause that rise? Maybe the market as a whole participate to make that happen, but what if someone powerful with lots of fiat money to burn just hoses their spare cash at one of these forks?

What if genuine market forces naturally (and likely slowly) turn the price disparity around after such a fork + price rise? Maybe the mainchain with BIP142 Segwit activated would regain the cryptocurrency number one spot, or the losing fork would (whichever that may be). Maybe the mainchain won't get activated with BIP142, never loses it's number one place in cryptocurrencies, and gets activated by BIP149 instead of any of these options.

There are probably dozens or permutations of what could happen, so simply wishing that the price doesn't fall ever isn't really detailed enough.

Simple bitcoin holders are already very tired of this news. Especially panic novices. I just want the situation to be resolved in the best way for everyone. And so that the price of bitcoin does not fall

Sort of pointless saying that when you go on to accept that on-chain is not what will give us the exponential growth in transaction volumes needed.



Me too. The margin that constitutes filling 90% full blocks up to 100% makes a huge difference to the dynamics of the fee market though. The users choose their price in that circumstance, it's a buyers market.


Well, for one, 8MB would be easy to spam: just get the right weight of sig-heavy transactions that fill up the witness blocks. So I'm not sure why you're saying that, filled up 8MB blocks would be all but inevitable if the Bitcoin user community accepted the Segwit "2x" hard fork variant.

And you're making the same point about "conciliating with big blockers" that you did already, so I will reiterate also: 4MB for the Segwit soft fork is already pretty big as a max size. The count of Bitcoin nodes on the network is healthy, but hardly mirroring the ATH range we have with the exchange rate. I'd be happier with Segwit 4MB if there was a clear jump in node numbers that demonstrated that all these new users understood that the strength in numbers on the Bitcoin network is the foundation of what makes BTC valuable in the first place. We will see, but this is hardly ideal circumstances for 4MB, let alone 8MB.



Let them. It cannot be sustained long term, despite the inevitable chaos. My advice: the more this vaunted hard fork is given credibility, the more the chaos Bitcoin will see. You're not doing very well at the talking-down-the-hard-fork-coup thus far, I suggest you fix that if you want minimum disruption to Bitcoin. I mean, people listen to you, right? That means you carry a little responsibility for how your words resonate within the community



I expect these things will indeed happen, one way or another

Yeah, I've only been around for little under a year but it's difficult to ignore the pattern even as a passer by. If the correlation is accurate, we'll be experiencing the next one in a matter of weeks. And the resources that have been mounting indicates that they'll have a strong appetite for a sustained battle of attrition.

From my own point of view, the original Segwit proposal is enough for now (until 2018/19). But if the growth of 40% per year continues, then in one or two years real transaction bottlenecks could emerge. I doubt most transactions were spam. Very probably we've now less transactions because of the holiday season in the Northern hemisphere and also because many users (also big ones like exchanges) have optimized their transaction behaviour to avoid the high fees.

But my comment was more directed to the power struggle - real "big blockers" don't want 2MB, they want 8 or even 32 MB. I don't agree with them because like you I believe we should concentrate on second-layer solutions, but I'm sure that 2MB+Segwit (8 MB max but we will probably never reach even 6MB) or Doomad's conservative flexible cap would cause no harm to decentralization. So it would have been an intelligent move by the Core devs to support a 2MB+Segwit variant with their own desires included (e.g. "all those nice features we can achieve with an hardfork" and delaying the hardfork to 2018).

Now instead, we'll have a bumpy ride, with a likely chain split and maybe a new reference client controlled mostly by miners.

i would like to hear the opinion from some less weird and cranky core developers. there hasn't been a great deal said by the rest of them.

my gut feeling is that this is more stalling and power grabbing that won't go very far, but i'm also not sure how much mining power bip 148 can attract.

Yea, those 5 ideas

If it just ends up being 80+% of miners and hardly any nodes, services or legitimate economic activity, then you'd certainly have a point.  That would indeed be a bad fork.  But such an outcome remains to be seen.  I suspect most users aren't nearly as diametrically opposed to the idea as you clearly are.  



"5 different ideas in 5 different months"?  If you mean the successive tweaks I've made to what I'm now calling SegWit Adaptive, that's what happens to new ideas.  They incrementally improve and evolve as time passes.  Basically the definition of the word "development".  Or would you prefer I had kept pushing BIP106 in it's original form, which could potentially (in the sense that the code permitted it) have resulted in a 32MB or 64MB blocksize in less than a year?  It simply wasn't practical to be implemented in that fashion, but the theory behind it is sound.  So, rather than discard it altogether, I set about trying to make it better.  



Have I entered into some sort of backwards-bizzarro-mirrorverse?  I thought it was you constantly proclaiming butthurt grievances over users' choice of software because you absolutely can't abide anything that proposes a change to consensus unless it's Core-approved.  What on earth are you on about?  I'm all for freedom of choice for users.  Well, I might have been a little harsh on the UASF mouthpieces, but only in pointing out the obvious in what a reckless and potentially stupid idea it was.  But I certainly don't begrudge them the right to run that code if they choose to.  I'm not into the habit of telling people what they can or can't run like you constantly try to appear not to do (but fail miserably).

Concurred. It is, however, difficult to ascertain what peak demand was at any given time recently, we've been in a world of politically driven transaction demand for, what, 2 years? A little longer? And this is likely a lull in that dynamic anyhow, you can bet that the mother of all spam floods is being prepped right now for the time when it's perpetrators need it the most.

That's a strange conclusion to draw from his concerns... if he were hoping for Bitcoin to crash as a network, he'd encourage a more reckless approach to scaling. It seems the opposite to me, Dashjr is in the far conservative camp, and there has been provided evidence that even at 1MB the network was vulnerable in his view. Those like him can be criticised as protectionist, but that's rather the behaviour of someone heavily vested.

@CarltonBanks re: demand for economic tx, yes! Although I do believe that this as well isn't accurately reflective of economic demand - trading volume is relenting across the board and perhaps this easing off is partially owing to speculation fatigue.

Up until recently, Luke was right, the evidence you request proved it.

And the evidence was? The number of copies of the Bitcoin software running the Bitcoin network. A few months ago, it was on a 3-4 year downward trend, the high was 8,000 Bitcoin nodes on the network in around 2013 or 2012. Now, we've come back up from a local low of 6,000 nodes to the healthier 7,500 number we have today, stimulated by Bitcoin's bull-run in the last few months.

You wanted evidence that Luke has a point, that's it. He's on the extreme end of the small-blocks spectrum, but the argument has merit, and empirical evidence to back it.



And so you're saying that 80% of miners agreeing to take the network in the exact direction they choose, with their own fork isn't a little "melodramatic" itself? And you appear to be defining "consensus" a little strangely, as if what the miners choose to do is the meaning of that word. Funny how you're the one always subtly pushing at the edges of what the Bitcoin developers want, isn't it? You've had about 5 different ideas in 5 different months about how "they're doing it wrong", you're basically just a walking/talking/singing/dancing Bitcoin hard-fork really, huh?

But you're right, the users will choose as they wish. I predict you'll continue to criticise both what the users choose (as you constantly do) and what the developers come up with (as you constantly do)





re: bolded, what for?

The easing off in the spam transactions recently only goes to show that demand for economic transactions (i.e. non-political transactions) was always artificial, the world still doesn't really need 350,00 Bitcoin transactions per day.

And even if they do, are you seriously trying to suggest that 4x the transaction supply is needed? Or that increasing the max blocksize to 4MB is not a compromise? Neither is true right now. Even if it were, the secondary network layers enabled after Segwit should be the focus, you know as well as I do that on-chain transactions will never scale, by definition.

I somewhat agree with Carlton Banks' interpretation. It is a power struggle. But the Core developers could have maintained a high degree of control over the code if they agreed to any compromise involving - even slightly - bigger blocks than the 1MB+Segwit variant. Now, if Segwit2x is a success and miners show overwhelming support to the 2MB hard fork, there is a chance for the Btc1 implementation taking the lead.

It is however possible that Luke is right and the agreement fails at the end - mainly because of Craig Wrights initiative to block Segwit with 20%+ of the hashrate, possibly having been agreed with Bitmain. In this case, having the choice between BIP148 and a "unlimited Bitmaincoin", I would (grudgingly) agree to support BIP148.

That's a tad melodramatic.  There isn't a single proposal out there that prevents anyone from writing code.  If a fork occurs, all developers will still be in full control of their respective repositories and they are perfectly free to decide if they want to follow the new fork or not, producing code accordingly.  If it were developers who decided what consensus was, then it would be about taking control of who writes the code, because that would be important.  But it doesn't work like that.  It's users who decide what consensus is and, as such, there is no control to take control of.



Again, there isn't a single proposal out there that prevents you from running whatever code you want.  It's just that if you want to take advantage of the security and hashpower provided by those miners, or the utility and service provided by those exchanges, you can't do that if you willingly choose to run code that isn't compatible with the code they're running.  You can't have your cake and eat it.  If you don't want to use the code enforced by the consensus mechanism, you are perfectly free not to.  That's your choice.  No one is putting a gun to your head and forcing you to follow any fork.  You are in full control of your money.  You even have the option of following both forks if you like.  That's how much control, freedom and choice you have.  But if you willingly choose not to follow consensus, you can't then also complain that you can't use those services, or have your tx confirmed by those miners.  That's what "taking your ball and going home" looks like.

I have always found it funny that people who do not agree with how others think, and how they speak themselves out, always are being put in the corner of those that don't understand how things work. Why isn't it possible to partially support a certain proposal? It has already been pointed out hundreds of times that Segwit on its own isn't going to gain any sort of significant support to activate it, which is exactly why a UASF has been put there to force through an activation of Segwit. If you closely look at both scenarios (activation through UASF or Segwit2x getting activated), then it's almost guaranteed that we'll be going through a difficult period of time with a widely divided community/economy. Just out of interest, what is your plan of action prior to the *potential* activation of Segwit2x?

Dashjr claims that 1 MB block size has been dangerous to Bitcoin and wants it to get reduced. Tells a lot about this guy. I believe that he has invested quite heavily in the alts such as Ethereum, and want to crash the Bitcoin exchange rates. If he claims that 1MB has caused a lot of harm, then let him give the evidence to prove the same.

No it isn't

It's no different to the other hard fork dev team coups, richardsNY. It has nothing to do with the good of the network, it's about taking control of who writes the code.

And that's what will happen if people follow this fork: the miners, the exchanges, and whoever lies behind those organisations, will start to dictate what code we all have to run. This is a dangerous precedent, you would do well to understand what the whole context is before making hasty statements such as the above

This is something that will never fully settle with entities looking to nurse their own ideology and vision. Obviously, I would have preferred to see SegWit being supported on a large scale, but the point is that we have to look at how the majority agrees on something -- after all, our main focus is to allow Bitcoin to cope with the increased demand, and thus to grow further. SegWit2X is a very decent alternative that I don't mind to support. Whether or not it will fail, that remains to be seen....

Bitcoin Core developer Luke Dashjr claims the goal of SegWit2x, a move to provide a minimal patch to resolve the conflict over activating SegWit and increase the block size to allow faster transactions on the bitcoin blockchain, is to stall SegWit.

Writing in Medium, Dashjr says SegWit2x’s beta can be broken into five categories. He begins with branding, the simplest part. Bitcoin Core 0.14.1 has become btc1 Core 1.14.3. The most interesting observation here is that it is based on the old 0.14.1 instead of the 0.14.2 that fixed a number of bugs, such as miniupnpc vulnerability.

Dashjr also does not understand the reason for testnet5, a new testnet. If one wanted to test a bitcoin change, they would do so as a change to testnet instead of making a new one. He does not see why a new testnet was developed.

Some policy changes take effect immediately upon switching to btc1, even ahead of activating a hard or soft fork. Transactions can now use up to 32k sigops instead of the 16k Core limit.
New Size and Sigop Limits

Miners and miner pools linked to a btc1 code claiming to support SegWit will be advised the size limit is 8 MB and the sigop limit 160k. This last part is most likely a bug since it should wait for the hard fork to activate. In practice, this does not make a difference because the block template provided will not overflow the limit. Dashjr is not aware of any miner who will add transactions reaching that limit.

Btc1 has the well-known BIP91 that limits the SegWit activation to 80% for a few days on bit 4. This is primarily the same as BIP148, although it gives miners with a 20% hashrate, such as Bitmain, a veto.
What The Hard Fork Brings

Then comes the actual hard fork. It does not really use bit 4, but it activates 12,960 blocks, 90 days, following SegWit’s activation, no matter how it activates. So even if Bitmain blocks SegWit2x, the btc1 nodes will still hard fork 90 days after SegWit is activated by BIP148. A hard fork will not occur if SegWit does not activate, but BIP148 is going to occur, so it will activate.

The hard fork itself includes an 8 MB maximum block size limit, with the code obfuscated to look like a 2 MB block, a 160k maximum block sigop limit (made to look like 20k), and an 8 M maximum block weight limit (compared to a typical 4 MB block size). As for the sighash scaling, a new 1 MB limit gets imposed on each transaction’s non-witness data.

The first block under the hard fork rules calls for more than 1 MB of non-witness data. Dashjr believes this could have been better accomplished using the hard fork bit to prevent reorgs from also affecting “SPV” light clients.

4 to 8 MB block sizes, according to Dashjr, do not make sense. Even 1 MB blocks have proven dangerous to bitcoin. He does not envision consenting to the hard fork under any circumstances, other than with a soft fork to keep the size reasonable. But even then, he would not support the proposal. If there is going to be a hard fork, some useful changes should be made, such as native merge mining, something Satoshi suggested as the first hard fork years ago. Or fixing some outstanding bugs like the time warp vulnerability.

Also read: Chinese bitcoin roundtable forum affirms support for SegWit2x
SegWit2x Hard Fork Will  Fail

Dashjr notes he is not the only one raising these issues, and he asserts that SegWit2x’s hard fork will fail.

SegWit2x’s real purpose, according to Dashjr, is to stall SegWit. He sees it as a distraction form the upcoming BIP148 soft fork that has already deployed irreversibly to the network. In promoting BIP91 and SegWi2x to be a BIP148 alternative, miners are really making another power grab to reclaim their veto, something that only exists as a way for Bitmain to block the whole initiative at the last minute.

If not enough of the economy upgrades to BIP148 by August, Bitmain gains the chance to execute a chain split attack and trick outdated nodes to follow their invalid chain, becoming financially dependent on it prior to grasping the attack’s occurrence.

The only answer is to create awareness of BIP148 and assure as much of the economy as possible has upgraded prior to August, Dashjr claims. This is true whether or not one supports SegWit’s hard fork. Even those opposed to SegWit should make everyone upgrade to BIP148, which does not prohibit SegWit2x or require anyone, including miners, to support SegWit.

BIP148 only requires miners can no longer stop others from adopting SegWit. With sufficient support, miners cannot execute a chain split against old nodes without paying a financial loss. There are no risks to running BIP148 if SegWit2x participants are honest, according to Dashjr. If they are not honest, BIP148 is needed to keep one’s node secure.

https://www.cryptocoinsnews.com/bitcoin-core-developer-claims-segwit2x-will-fail-claims-its-goal-is-to-stall-segwit/