Why you should oppose Segwit2x to bring an end to the blocksize debate

Read about Prohashing, mining, and coins in general!
Forum rules
Sign up to be notified of new posts to the Prohashing Blog at http://eepurl.com/gx1e0j
Post Reply
User avatar
Steve Sokolowski
Posts: 3954
Joined: Wed Aug 27, 2014 3:27 pm
Location: State College, PA

Why you should oppose Segwit2x to bring an end to the blocksize debate

Post by Steve Sokolowski » Mon Jul 17, 2017 6:53 am

For some time, I've been preparing an argument as to why the Segwit2x proposal for Bitcoin is a poor choice, and over those weeks, I've become more and more convinced that we have an opportunity to resolve the blocksize debate once and for all this week by abandoning pools that are supporting the proposal.

In addition to taking the longest, this is probably the most important post I have written.  In this lengthy article, I'll attempt to present a comprehensive case as to why miners should oppose Segwit2x by switching to pools that will not signal for Segwit2x.

Technically, Segwit is a complex solution to a much simpler problem that will make it difficult for developers to develop for Bitcoin in the future.  Interpersonally, Segwit2x doesn't address the primary issue facing Bitcoin: the irreconcilable differences between the Core and those who support bigger blocks.  Logically, Segwit2x doesn't represent a "compromise," as is advertised.  Ethically, Segwit2x is about the wrong people making decisions for which they will not suffer the consequences.  There are many more reasons that I can't list in this introduction.  Finally, I'll propose that the entire process of solving this problem has been considered too narrowly and that the solution already exists.

The best way to address all of the issues with Segwit2x is simply to list them and review each in turn, which I'll start now. At the end, I'll explain how the best outcome is to simply allow the forks to occur now, and why the world isn't going to end if Bitcoin forks.


A 2MB blocksize is not large enough

Segwit2x proposes the activation of Segwit within a few weeks, followed by a hard fork to a 2MB blocksize for Bitcoin a few months later.  Since the proposal was decided behind closed doors, it is not possible to determine why the participants chose 2MB as the blocksize limit, but this limit is arbitrary and has no grounding in any mathematical formula or experimental evidence.  The obvious indication that is so is because the odds are extremely low that any calculation to determine the optimal blocksize for Bitcoin would result in exactly 2MB, not one byte more or less.

The 2MB limit the participants have decided upon is permanent.  There are absolutely no plans to increase the blocksize limit if the 2MB activation is achieved.  This decision represents an appalling lack of foresight.

Let's imagine if, when it was determined the IPv4 protocol was insufficient, the companies who designed the successor IPv6 had decided to simply double the number of IP addresses available.  What would have happened when the protocol was announced?  Would Cisco immediately begin implementing it in all of its new routers?  Of course not - they would have seen that the investment required to reimplement the new protocol in all of their products was absurdly high compared to the possible gains.

This lack of action is exactly what will happen if Segwit2x passes.  Companies like ours, which have already switched to Litecoin, are not going to consider Bitcoin a serious contender with such a ridiculously small change.  Notice that Litecoin right now already has higher capacity than Segwit2x will provide in four months, if it were to activate as designed.  Possible new developers and merchants aren't going to look at Bitcoin, be amazed by the new capacity it brings, and start developing great apps for it.

What will actually happen is that the blocks will immediately become full again, nobody will be impressed by such a trivial change, and the growth will continue to be in Ethereum and DASH, where the blocksize issue is already solvable and communities are not poisoned by their development teams.

The proposal does not address the people problems

Speaking of development teams, Segwit2x proports to solve the blocksize issue without actually addressing the problem that caused it:  the presence of Michael Marquadt. While some developers have supported Marquadt, his actions are directly responsible for the current situation.

Since Michael Marquadt (theymos) split the Bitcoin community in August 2015, Bitcoin community participants have been at odds with each other. Marquadt controls reddit's largest Bitcoin subreddit, the popular bitcointalk.org forums, and his influence (whether intentional or not) extends to biased "journalism" on many industry websites.  He repeatedly uses his accounts to promote the Bitcoin Core and to disparage supporters of alternative ideas, like Bitcoin XT and Bitcoin Unlimited.

Marquadt is treated by some people as an annoyance who isn't involved in any actual decisions.  While it is true that Marquadt is not a developer, and the industry is larger than his media domain, his actions singlehandedly created the current stalemate by preventing people from communicating with each other, which led to distrust and an inability to compromise.  Marquadt is able to maintain control because he has been able to promote increasing current blocksize limit as a "threat" to the Bitcoin network.  If the blocksize controversy were resolved, then Marquadt's influence would effectively be eliminated.

Additionally, the Core developers are unwavering on making any changes to Bitcoin's capacity whatsoever.  Last year, I published a chart describing various "compromises" that have steadily declined in size until now 2MB is considered by the Core to be too large. It should be obvious to everyone that the Core desperately wants to go its own way. People like me, who personally believe that the Core's actions are abhorrent, think Bitcoin would be better off without them, and I'm sure that the Core probably thinks the same of people like me. At this point, it's not about who is right; it's about getting Marquadt out of everyone's lives so that both sides can do what they want to do.

So why is everyone continuing to pretend that an agreement can be reached? What will change in 3 months that hasn't changed in years?

The 80% threshold does not represent true miner support

Proponents of Segwit2x point to the coinbase transactions of recently mined Bitcoin blocks to suggest that up to 83% of "miners" support the proposal.  This argument represents a lack of understanding of what these messages mean.

First, the "signaling" of Segwit2x blocks will not actually cause activation or prompt any other action.  The current figures are essentially "pre-signaling."  The blocks state that the organization that mined the block thinks they want to mine Segwit2x, when it is released, if there are no technical problems, and if they have the same amount of hashrate in late July. No software takes any action based on these messages except for a few websites that display statistics.

But there is also a critical flaw in these signaling statistics: most of these blocks are published by the software of mining pools, not by solo miners.  Miners can easily change pools.  In SHA-256 mining, the margins are much lower than scrypt mining, so Bitcoin mining has become a commodity service, with some pools actually offering zero fees.

There is reason to suspect that miners are uninformed about the Segwit2x proposal, which is one of the reasons why I decided to publish this article.  Our business has found that some miners simply set their equipment and come back to it weeks later; in some cases, significant amounts of money are stolen as customers fail to notice for days that their payout addresses were changed by criminals due to password reuse.  Most miners were not invited to the secret discussions that lead to the agreement, so it is to be expected that pool owners, who were invited, would be more enthusiastic about it than miners are likely to be.

Given enough education, it's reasonable to believe that 3% of all miners might switch their position on the proposal from "undecided" to "no."  Since signaling has not yet begun, Segwit2x hasn't yet reached saturation coverage.

To add to the issue of miners and pools, there is also the problem of changing production code on complex systems in a very short activation window.  I'll write more about this later, but some pools will undoubtedly fail to get Segwit2x implemented in time because we ourselves accidentally mined non-Segwit blocks during the signaling period for Litecoin given that it is far easier to change coinbase messages than to implement Segwit.

I fail to see how, given such a small margin of error, 3% of all miners will not find out about the proposal and decide switch pools, and/or 96% of the miners who want to signal Segwit2x will be able to implement it flawlessly when only a very small fraction of Segwit blocks can be lost during the two day activation period. Note that it is possible that these numbers have changed since

Segwit2x is not a compromise

Segwit2x is presented as a "compromise" solution for the blocksize debate, but relatively few people consider it an acceptable compromise except for the people in the room when it was decided.

There are two opposing sides in the blocksize controversy.  One side mostly supports Segregated Witness with no other improvements, and the other side mostly supports Bitcoin Unlimited without Segregated Witness.  The compromise seems pretty obvious: take the current Core code and modify it to support Unlimited's signaling rules.  That leads to a Segwit-Unlimited proposal, in which everyone can find something to like.  I don't like Segwit, but can just use normal transactions because there is space in the large blocks.  Lightning Network supporters don't need the large blocks, but the Segwit transactions will allow them to move forward.  That's a win-win proposal that would satisfy almost everyone.

By contrast, Segwit2x is a lose-lose proposal, which is why I'm mystified that the owners of mining pools have come up with it.  The Core developers will not support it in any way because they view anything created without their input as unacceptable.  The user-activated-soft-fork supporters are rightfully mad that Segwit2x essentially co-opts their planned fork, which they should be entitled to execute if they choose to do so.  Bitcoin Unlimited supporters see the absurdity of the arbitrary choice of 2MB.  The "compromise" is unacceptable to everyone because it doesn't contain any element that any side wants so much that they would be willing to give up something else.

A review of the positive press surrounding Segwit2x focuses on one primary theme, which even insiders frequently acknowledge: it is an effort to get something, no matter how bad, achieved.  Many of these people openly state that their main goal is to avoid a split solely to keep the price of Bitcoin high so that they can earn money, rather than taking the hard steps necessary to actually solve the problem and create a technology that will change the world.

This is what happens when a group who is out of touch with the people who actually use bitcoin for daily commerce and transactions draws up a proposal.  We've seen this happen around the world where citizens vote against "elites" they perceive to be dictating policy to them. I suspect that users, who are disgusted with the lack of transparency surrounding this deal, will not sit idly by and do nothing about it.

Segwit has risks its deployment on Litecoin demonstrated unintended consequences

For the past year, the Core has been trying to frame Bitcoin Unlimited as an unstable, insecure, poorly developed piece of software.  To accomplish this goal, they have revealed denial-of-service vulnerabilities in the client that can cause it to crash (but have never caused any losses of money.)  While it is possible that Bitcoin Unlimited actually does have more bugs than Bitcoin Core does, my experience leads me to believe that all software has lots of bugs, and the major reason that Bitcoin Unlimited has crashed so often is because Core developers are spending their time trying to find issues and publicize them.   The way in which the issues were revealed publicly instead of notifying developers or submitting pull requests for patches is questionable practice.

Now that Segwit2x has come out, many of these same people are ready to forge forward with Segwit2x, giving miners just a few days to implement the software when a single mistake costs $40,000.

When Litecoin's Segwit implementation activated, a major pool that represented about half the hashrate of the network had issues with publishing blocks.  At the same time, we tested and deployed code that successfully published Segwit blocks - and which then stopped working because a race condition had been very lucky and had made it appear that the code was working when in reality the timing was just right for the first few blocks.

The rapid deployment schedule of a two-day activation period(!) raises three separate concerns.  The first concern is obvious: even when things work great in development, they often come out very differently in production.  The testnet is not a complete substitute for the real world.  During long activation periods, different pools and miners make the switch at different times, so the risk of chaos is diminished.  With Segwit2x, there is a good chance that the Bitcoin network will have extremely poor usability initially, because blocks will be lost due to bugs and they will therefore be infrequent.  When enough independent trials of a rare event are undertaken, rare things tend to happen.

The second issue is that since the activation period is so short, there is no time to recover from mistakes.    In fact, even if all 83% of the miners who intend to signal Segwit actually attempt to do so, the margin of error will be just 8 blocks of the 288 expected over the course of two days.  It's difficult for me to believe that with everyone using new software over that period and rushing to make these changes with just a few weeks to prepare, fewer than 9 blocks will be orphaned or lost as a result.

The third issue is that the 2-day activation period is so short that simple luck could cause activation to occur or fail even if 80% of actual hashrate supports the proposal.

Segwit2x is far riskier than Bitcoin Unlimited.  In addition to introducing new data structures on the Bitcoin network whereas Bitcoin Unlimited just increases the size of existing data, Segwit2x attempts to do this over the course of two days, with almost no advance preparation time.

Segwit2x requires more forks than any other proposal

Segwit2x will be a different fork from the original Bitcoin with no capacity increase with Segwit enabled because the capacity increase does not occur at the same time as Segwit activation. People who support only Segwit but not the capacity increase cannot be compelled to uphold their end of the bargain and continue mining the "single" chain.

Also unique to Segwit2x across any of the presented options is the effect it will have on cryptocurrency in general.  Not only will there be the 2MB hard fork, but Segwit2x will result in at least three coins that are derived from Bitcoin:  the original Bitcoin with Segwit enabled, Segwit2x, and then future proposals like Segwit3x and beyond, because each one with a new blocksize limit will be a different fork.

The problem of multiple forks is guaranteed by the signatories' lack of foresight.  In their haste to come to an agreement and to avoid a "contentious split" at all costs, they may achieve the opposite effect: diluting the marketplace with so many Bitcoins and people who claim that a certain Bitcoin is the universal one, and the one they prefer loses traction.

A large part of this danger is a result of a precedent having been set by the action of taking temporary action.  If many miners mine the new chain, then it's likely that many will see Segwit2x as having "worked."  Since it worked this time, why isn't it acceptable to do the exact same thing next time, and double the blocksize again?  Whatever action is taken for the first chain split will be the standard against which future actions are measured. Bitcoin Unlimited avoids the problem by allowing miners to choose the size of blocks to accept without a fork. Whether Unlimited blocks are adopted or not, the miners still have to agree to accept them; the only difference is whether a fork occurs or not.

SegWit2x creates, rather than solves, problems because its proponents fail to see that miners still have to agree to accept larger blocks no matter what the maximum blocksize is set at.  Those who support any hardcoded blocksize proposal are simply committing to diluting Bitcoin's utility across multiple forks whenever a majority of miners agree that the next capacity increase is required.  This is illogical.

Why users, not miners, developers, or rich investors, will make the best decision

Far from being a new economic model that cuts out corrupt banks and which is accessible to the common man, Bitcoin has become co-opted by moneyed interests who are interested in nothing more than propping up its price to protect their profits.

The signatories behind the closed-door meeting did not include mom-and-pop merchants and investors.  The list, which is available online, is dominated by the CEOs of large businesses and investors like Barry Silbert, who played a role last summer in creating an enormous bubble in Ethereum Classic, which enriched the thieves of the DAO beyond what probably they even hoped.  Noticeably absent from the list are those who use Bitcoin for everyday transactions, who are more interested in creating a free currency, who work full-time or more for a living in other industries, and who don't have the time and can't afford to be a jetsetter to these conferences - people like you and me.

Fortunately, there is a way to allow everyone to have a say - to present them with a single and decisive date with multiple forks and to let the best one win.  The problem with anyone other than users in the market making this decision is that the end result will be a coin used by a small number of users to the benefit of miners and big corporations.  If several choices are presented to the market, then users will obviously flock to the one with the cheapest transaction fees, and the miners, developers, and corporations will be forced to deliver on the fork that is the most useful to the world.

Of course, if the miners, developers, and investors succeed in forcing a crippled 2MB Bitcoin fork on the world, then users aren't going to just go along; they'll continue to move to other coins, where there is more certainty and capability.

Segwit is a poor solution in general

I've repeated my objections to Segwit many times in the past, so I'm not going to review them all here.  You can read them from previous posts.  Instead, I'll just provide a general overview.

While there are other benefits, proponents of Segwit present it as mandatory to activate the Lightning Network, which is supposed to allow extremely cheap transactions on "payment channels" that are not tracked on the Bitcoin blockchain.  The key problem preventing the Lightning Network from activating is transaction malleability, which makes it possible for anyone to create a different transaction ID for a given transaction after it has been published to the network.

If users want to activate the Lightning Network, then malleability has much simpler solutions than Segwit.  Segwit has become a monstrosity because Core developers rolled it out as a catch-all.  At the same time as solving malleability, they promised to execute it as a soft fork, so that existing users would not be affected (which isn't true), as well as increase the blocksize by a factor of four (which also isn't true)! In fact, the opposition of many users to Segwit comes not from the proposal itself, but because it isn't a hard fork.

But here's what Segwit supporters often don't publicize - for some of the most common uses of Bitcoin - the smallest and simplest transactions - Segwit actually requires more bandwidth and disk space than the existing transaction format!  In return for this, perhaps 30% more transactions might fit in the initial 1MB block - an optimistic assumption, with good uptake of Segwit.

Once Segwit activates, it can never be reverted.  Every block explorer will need to be rewritten to support Segwit transactions.  In Litecoin, for example, there aren't any block explorers that can actually interpret Segwit transactions yet! Plus, the "soft fork," rather than preventing errors, will enable a whole class of attacks that can take advantage of nodes who treat Segwit transactions as being spendable by anyone.

Finally, for those willing to overlook all of that because they believe the Lightning Network can solve all of Bitcoin's problems, consider that money on the Lightning Network is not useful until it is actually sent to a payment channel.  That requires a transaction fee, just like any other transaction.  It's ridiculous to suggest that all of the transactions between payment channels can be handled with just 2MB of block space for all time.

If it is activated, Segwit's complexity will haunt developers for years to come.  There are far better ways to solve the malleability problem, which is the major issue that Segwit was designed to address.  Since the Core has been unwilling to consider any other solution, those who would prefer to consider alternatives to Segwit should support a hard fork and look towards activating a different solution at a later time.

Profit switching pools will provide hashrate to the forks

A common belief is that miners won't "choose" a large-blocksize fork. When a client supporting a fork is available, miners are actually the least important group in deciding the fork's success.

If a hard fork is forced, the Bitcoin community will be presented with a number of coins calling themselves "Bitcoin." At first, investors will buy these coins based upon what they perceive as their probability of success. Later, the coins will start to be valued at their actual usage. But since all the coins are planned to remain with SHA-256 mining, pools will quickly appear that will automatically switch between the networks to achieve maximum profitability for miners. Indeed, We had originally planned to provide switching between the forks as a new service before we recognized that we had too little capacity and decided not to invest in expansion.

Profit-switching pools will make the hashrate of these forks irrelevant to their usage and investment. Hashrate of a coin is always correlated with price and block time, and once the forks occur, miners who do not use profit-switching pools will be sacrificing profit by mining only one of the networks. Profit-switching pools quickly appeared once Ethereum and Ethereum Classic split, despite the vast majority of miners "voting" in favor of reverting the DAO. Since the two coins had the same block time, hashrate quickly mirrored the ratio between the prices of the coins. The same would happen across multiple Bitcoin forks, regardless of what many miners say they are going to do at first

Segwit2x does not resolve the uncertainty problem

Perhaps most importantly, Segwit2x doesn't solve the #1 problem facing us and other cryptocurrency businesses: uncertainty.

For the past three months, we've been in a weird holding pattern. Our project is collapsing under the weight of support tickets, and we cannot get enough performance out of the system to support all the potential customers. Every time we are able to improve the software by another 5%, more customers come and overload the system again. This issue has delayed new features that could make even more money: for example, we aren't mining SHA-256 because it doesn't make sense to deploy new algorithms when we could simply expand capacity for existing algorithms. Methods to resolve these performance issues are nothing new; they just take a developer working on the problem spending time with common optimization techniques.

There is enough money to hire someone to do this work, but it doesn't make sense to train and supervise someone when you yourself could be doing the work instead. If I could work 70 hours per week on this system instead of the 25 I can now, then our performance issues would probably be able to get ahead of, or at least get closer to, the true demand. Then, we wouldn't need to hire anyone, or we could at least hire someone and I could supervise her.

But there is no way I will ever quit a job that provides healthcare in an era when Republicans are willing to destroy the preexisting conditions protections unless I can run budget numbers on what our expected profits and expenses are going to be. That budgeting is impossible to perform because Segwit2x will indefinitely delay the growth of the Bitcoin network. With Segwit2x, we can't ensure profitability 6 months from now, because the Bitcoin war is going to continue to fester and drag down growth.

If you want businessmen to take Bitcoin seriously and stop seeing this space as a rogue planet where criminals rule and investors play games with each other, then provide them with a platform that has a definite future. A good example here is Alexa, which was locked in as the standard for voice by Amazon's record sales of Echo devices on Thursday. Developers are flocking to Alexa because they now know which platform will be the standard. An immense amount of investment (like mine) and talent is being diverted from Bitcoin to other industries while people wait for a permanent solution to this problem.

Why are Segwit and the Lightning Network needed anyway?

I'll conclude with the most pertinent reason to oppose Segwit2x, and the one which few seem to be talking about.

The Lightning Network appears to be intended primarily as a way to move transactions off the Bitcoin blockchain, and Segwit exists primarily to solve transaction malleability, which enables the Lightning Network. But in the two years since these two concepts garnered widespread attention, the world has changed a great deal. In particular, instead of one main cryptocurrency network, there are now tens or hundreds of coins that have significant value and which are used to move money around.

What is the difference between taking money off the Bitcoin chain onto a payment channel, doing lots of transactions, and then bringing it back onto the Bitcoin chain, compared to converting money to Litecoins or DASH or Bitconnectcoins, doing lots of transactions, and then converting it back to Bitcoins?

The Lightning Network is complex, requires major changes to the Bitcoin protocol, and significantly limits the capabilities of the "payment channels." A multi-currency wallet is simple, only requires expanding the Bitcoin blocksize, and people can create coins with new features with few restrictions or costs. Exchanging coins can be decentralized, and by the way, this idea of using small coins for most transactions already exists and works pretty well for us.

If people want to develop the Lightning Network, that's great. They should be allowed to do so without forcing the changes on everyone else. It's not necessary to argue anymore that it's the only way to move transactions off-chain, however.


In conclusion, Segwit2x is a proposal favored by rich investors to protect their money by avoiding at all costs the chain split that is necessary to result in a permanent solution to the blocksize controversy. Segwit2x is not a compromise, as it does not make anyone happy about anything except that the other side didn't win. It does not end the debate, and does not address the uncertainty issue that is the main reason why cryptocurrency is dominated by amateurs, part-timers, and criminals. It does nothing to address people like Michael Marquadt, who would remain part of the single coin community. If Bitcoin survives long enough to warrant them, there will actually be more "forks" of Bitcoin starting with Segwit2x, each with various blocksizes, than there would be if the network split now.

As the past few days have begun to show, Segwit2x won't even succeed at its primary goal: to maintain the price of bitcoin. Even for those who are clinging to Segwit2x as a way to sustain the price of Bitcoin, I find it hard to believe that the total price of the current forks, or the Segwit2x/Core fork in October, holds above $980.

There is a better path available. Finally, after years of talk, the BitcoinABC client has finally been released and will force a hard fork on August 1. I firmly believe that if Segwit2x is defeated, a final decision will be evident within 2 months, because BitcoinABC provides a unilateral hard fork as an alternative for the first time ever. Regardless of whether you believe that Bitcoin should never be changed, whether you like Segwit, whether you support big blocks, or whether you simply desire an end to the debate, we have the opportunity to put the question to users on August 1. Segwit2x, on the other hand, will indefinitely delay a resolution to the most critical issue facing Bitcoin.

If you have miners mining at a pool that has declared support for Segwit2x, I urge you to move them to a pool that opposes the proposal, or to solo mine without Segwit2x signaling. Only a few percent of Bitcoin miners need to make this decision to execute a dramatic change. If Segwit2x is defeated, a three-fork ecosystem will emerge:
  • The user-activated soft fork will allow users who support Segwit and the Core to further development of the Lightning Network without interference from others.
  • The original bitcoin fork will appeal to those who have supported the idea that Bitcoin should not change from its original design.
  • The Bitcoin ABC fork will allow for more transactions for users who just want to send money but are priced out of the current network.
Exchanges will list these forks, because the market leadership will be lost for those who insist on one of them being the "one true Bitcoin." Tonight, Chris will be contacting the owner of Novaexchange to request that BitcoinABC and the User Activated Soft Fork (UASF) be added for trading. Then, users will buy and sell to determine for themselves what Bitcoin should be. It will be the end of forum attacks and sockpuppets, we'll know what public opinion actually is, and soon

the debate will be over.

That one is in bold for a reason. Surely I'm not the only person who finds it difficult to imagine the relief when we can wake up to different groups of people executing different visions, who are actually spending their time productively instead of attacking each other. That might happen within weeks, or it might take months, but it will certainly be quicker than Segwit2x promises.

Please join me in opposing Segwit2x. Whatever your political beliefs, users should have the right to decide. Move your miners to pools that oppose the proposal as soon as possible. Segwit2x can be deployed as early as July 21, so you can't wait until August to switch; you need to do it within days. We have an opportunity to put an end to this debate once and for all, and every last miner can make a difference.
Posts: 2
Joined: Sat Jun 04, 2016 9:47 am

Re: Why you should oppose Segwit2x to bring an end to the blocksize debate

Post by johnWorthley » Wed Jul 19, 2017 12:24 am

Hi Steve,

Any thoughts on the implications of Bitcoin Cash being listed as BCC, the same three letter sequence as Bitconnect? This could get confusing.
User avatar
Steve Sokolowski
Posts: 3954
Joined: Wed Aug 27, 2014 3:27 pm
Location: State College, PA

Re: Why you should oppose Segwit2x to bring an end to the blocksize debate

Post by Steve Sokolowski » Sun Jul 23, 2017 7:17 am

johnWorthley wrote:Hi Steve,

Any thoughts on the implications of Bitcoin Cash being listed as BCC, the same three letter sequence as Bitconnect? This could get confusing.
I think I'll refer to this new coin as "BTCC," as that makes a lot more sense and easily differentiates the two coins.
User avatar
Posts: 79
Joined: Wed Jan 07, 2015 3:14 pm

Re: Why you should oppose Segwit2x to bring an end to the blocksize debate

Post by rootdude » Thu Jul 27, 2017 6:39 pm

Hey Steve -

I get what you're saying... but you should also understand the ramifications of voicing even a rational argument for one side or another. DDOS attacks... which cost you, and all of us, coins - that's the bottom line as I see it. We all have 1st Amendment rights of expression, but also have to deal with the consequences of holding and voicing those opinions.

For us, your customers/partners, we also have to deal with those consequences when they result in attacks on the pool.

Thought you might like to know how some of us feel about that.
Posts: 665
Joined: Sun Apr 16, 2017 3:01 pm

Re: Why you should oppose Segwit2x to bring an end to the blocksize debate

Post by GregoryGHarding » Thu Jul 27, 2017 7:14 pm

rootdude wrote:Hey Steve -

I get what you're saying... but you should also understand the ramifications of voicing even a rational argument for one side or another. DDOS attacks... which cost you, and all of us, coins - that's the bottom line as I see it. We all have 1st Amendment rights of expression, but also have to deal with the consequences of holding and voicing those opinions.

For us, your customers/partners, we also have to deal with those consequences when they result in attacks on the pool.

Thought you might like to know how some of us feel about that.
are you asserting that steve's opinion blog was the cause of the ddos attacks? if so, how do you know?
User avatar
Posts: 121
Joined: Sun Apr 16, 2017 12:51 pm

Re: Why you should oppose Segwit2x to bring an end to the blocksize debate

Post by FRISKIE » Fri Jul 28, 2017 1:26 pm

are you asserting that steve's opinion blog was the cause of the ddos attacks? if so, how do you know?
I admit to having wondered the same thing myself, then I settled on the opinion that;

A - it doesn't matter because attacks will happen regardless and we may as well harden the defenses already


B - Pool owners are by default influential members of the community and expected to have opinions

Besides the fact that I largely agreed with Steve's position (still do) and came away better educated with a side of the story that has been largely shouted down throughout the debate
User avatar
Steve Sokolowski
Posts: 3954
Joined: Wed Aug 27, 2014 3:27 pm
Location: State College, PA

Re: Why you should oppose Segwit2x to bring an end to the blocksize debate

Post by Steve Sokolowski » Fri Jul 28, 2017 5:09 pm

rootdude wrote:Hey Steve -

I get what you're saying... but you should also understand the ramifications of voicing even a rational argument for one side or another. DDOS attacks... which cost you, and all of us, coins - that's the bottom line as I see it. We all have 1st Amendment rights of expression, but also have to deal with the consequences of holding and voicing those opinions.

For us, your customers/partners, we also have to deal with those consequences when they result in attacks on the pool.

Thought you might like to know how some of us feel about that.
If attackers were trying to make a point that I should stop writing, then they did a pretty poor job of it. The idiots took down the E-Mail server where they could have sent their demands, so we obviously never received them.
Post Reply