|
BTCCC COO Samson Mow: Dear Chinese miners, mine owners, and exchange CEOs: The purpose of this email is to reach a consensus through negotiation. Some summary of the current situation: 1) The vast majority of miners do not agree with a controversial hard fork.
2) Core agrees to start discussing what the hard fork should do and when it can be safely implemented.
3) We all agree that we must calm the market turmoil and restore confidence in Bitcoin as soon as possible.
4) We all agree that the next step is to have business leaders draft a letter of appeal, asking everyone to wait for a while for Core to draft a hard fork plan. Do not support the launch of the hard fork in the meantime. Thank you for your understanding.
5) Core will release a statement in a few weeks to clarify their plans. If you have any questions, please contact me.
Stephen Pair, CEO of Bitpay: Forks are by definition non-contentious (especially requiring supermajority approval). I strongly recommend deploying the code needed to fork Bitcoin to allow blocks to increase to 2MB (regardless of which fork you are running). Hard forks will not actually happen unless a majority of miners support it (in which case, they will not be controversial). Code such a fork is built into the Bitcoin software project, and developers will neither support nor oppose it… they cannot force miners to activate such a fork, nor can they prevent it. If the fork is not activated after a period of time, it will be invalidated (if necessary, the code can be completely removed after the time expires). Generally speaking, if you are certain that the community supports a fork (hard or soft) and the project team does not have any technical flaws, then my opinion is that the code to activate the fork should be put into the project. Then let the miners decide whether to activate the fork. And the miners should listen to the needs of customers and any technical arguments, both for and against. I also think that mining pools are playing an increasingly important role in modifying consensus code. I think responsible mining pool operators should learn and consider any fork proposals. They should evaluate these proposals and advise miners on whether they should support a certain proposal. Then, miners decide whether to lend their computing power to activate the fork.
Smartwallet Dino Mark A: The main controversy right now is what is the definition of “majority consensus.” From conversations I’ve had with different stakeholders, most people think that a 75% threshold is a contentious fork. Regarding the mining pool's suggestion, I agree that they should allow miners to set a flag to choose the fork. Whether or not to choose a specific fork is a good idea and this should be a topic of conversation at industry summits where all stakeholders (developers, exchanges, miners, wallet providers, consulting firms, VCs, etc.) can provide feedback, research, and proposals and try to reach a consensus based on calm and rational technical/economic discussions. The current situation where we have only a handful of developers maintaining a fork (from what I understand Jeff and Gavin are only advising) against hundreds of other developers, and then some are secretly lobbying miners to adopt this fork, is not good for the long-term health of the project. To date, there has been no open communication channel between Chinese miners and core developers, and as a result, they do not have enough information to make an informed decision. I believe that as long as things like this continue to happen, we will continue to see bad news and uncertainty in the market.
Stephen Pair, CEO of Bitpay: I think your view on Jeff and Gavin opposing the opinions of hundreds of developers is wrong. Most of the amateur Bitcoin enthusiasts you see like to speak freely on social media, but only a few are well-informed. There are also many very talented professional Bitcoin developers who don't like to waste their time on social media. You need to allow blocks to scale (but carefully and moderately) so that we feel some pain of scalability limits and with a growing user base we create economic incentives to improve scalability. I have never heard any engineer say that if the Bitcoin block size is expanded to 2MB, Bitcoin will collapse or even die. I think getting Bitcoin Core developers on board would be a good idea, but I doubt the chances of it happening.
Smartwallet Dino Mark A: Just to be clear, I'm talking about the dozens of developers who signed the (Bitcoin Core) scalability roadmap, and the hundreds of Bitcoin Core contributors, and no one other than jtoomin is maintaining the Classic fork (that I know of). It's clear that the vast majority of good developers don't agree with the Classic way. No one thinks Bitcoin will die if it expands to 2MB, I agree, in fact every developer thinks we need bigger blocks (including core!). The question now is what is the safest way to do a hard fork, what we need to do to ensure safety, and what the timeline will be. I support Gavin's BIP (Bitcoin Improvement Proposal)... The process, timelines and thresholds are sound. The threshold to activate a fork must be high enough so there is no risk of a reversal... It must also be low enough that a small branch cannot have the power to veto a fork. The emergence of forks like Classic/XT was unwelcome; some developers were divided, they tried to attempt a politically contentious hard fork, and then we had a civil war on social media such as reddit without sufficient information. I'm not sure you're immune to this. Alternative projects are a good thing and should be encouraged. You never know, some of them may have better structure and leadership than Bitcoin Core. I'd like to see projects adopt an engineering mindset, not a computer mindset. I'm not worried that the Bitcoin Core project is doing too much experimental stuff. For example, segregated witness should not be included in the scalability and block size debate. It's a good idea (mainly because it solves the scalability problem), but it's also an invasive and risky change. It requires a lot of changes to existing software (not just Bitcoin Core). This shouldn't be rushed, but right now it seems to be just to avoid a hard fork. I think this is a symptom of the core developers' computer thinking over engineering thinking. Another thing I’ve heard in the community is… We’ve heard a lot of random people we don’t know trying to encourage BitPay to take sides against Bitcoin Core, and are incentivized to do so. They seem to be intentionally creating discord. These people are either trying to sabotage Bitcoin, or they’re just toxic people that we need to ignore. As a community, we need to figure out how to protect ourselves from toxic people… This reminds me of a conversation I had on this topic (which I recommend you check out): https://www.youtube.com/watch?v=Q52kFL8zVoM We should calm down and come up with a formal mechanism to deal with future hard fork (HF) upgrades to avoid this happening again. If every Bitcoin upgrade has such a hard fork fight, or worse, a contentious hard fork causes BTC to be lost in a bad chain, it will be difficult for the financial market to have confidence in Bitcoin as a viable/stable long-term holding asset. If such changes were easy, I would be more worried about Bitcoin. Although I agree with you that we should try to calm down. We do need to gain experience and become proficient in managing forks (whether soft or hard). This is very important for the future of Bitcoin. If the community becomes proficient, it will reduce a lot of tension, even for controversial changes.
Alex Petrov, CIO of Bitfury: Stephen, if you agree on the statement and have no different opinions, you can always sign it.
BTCC Samson Mow: @Stephen Thanks for taking the time to read this letter! You are welcome to sign on your own behalf. There will be a lot of miners supporting it, as well as exchanges and wallets. We are all part of this. Either we can send a unified message asking developers to get involved, or we will continue to watch the drama of Classic, and then the next drama. I also added Charlie Lee to the email discussion and invited him to consider signing the statement.
Brian Armstrong, CEO of Coinbase: I agree with Stephen, 70%+ of the forks are "contentious", there is no way around it. As long as they scale to 2MB and the code is well written, I am fine running any fork. I have no preference for any development team. Right now, Classic seems to be the closest to doing this, and their fork code was written and reviewed by two strong core developers (Gavin and Garzik). Samson, I believe you may be misinformed about miners supporting Classic. They have recently been visiting some miners and claiming support from Bitmain, Slush, KNC, and others. You may have information that I don't, but I think it's inaccurate to say that most miners won't support this. Right now we don't know. I also don’t think another open letter would have much of an impact. Core can make the decisions about what they want to build, and we can make the decisions about what we want to run. There’s no reason for us to try to convince them if there are other good options.
BTCC Samson Mow: @Brian Segwit can almost achieve the effect of 2MB expansion, and it is also the safest and fastest available. Remember, I am on the side of hard fork (HF) before segwit (SW), but here we need to adopt segwit. Regarding miners, the information I have is relatively accurate :) @Sam, you said you wanted a clear deadline, do you want to say something?
KNC Sam Cole: Everyone. Most of the developers we were trying to convince had never listened to this type of approach before. My fear was that two weeks wouldn't change their minds, and we were just doing the same thing over and over again, hoping for a different result. So, I hope it works this time, but I don't think it will change. So, we as a company will push classic. If core refuses to listen, it will give you everything it points to. I just think that after a year of debate over block size, it’s time to admit that we need to try something different. As for the soft fork of Segregated Verification, the code it actually requires is not that simple.
Alex Petrov, Bitfury: Hello Sam, we understand what you mean and we respect your choice. You may sign our statement or choose not to. We have communicated with developers on both sides. The Core team has improved their communication and expressed willingness to cooperate. (To be honest, it is classic that is helping improve core).
Only if we have the conversation will we be ready to resolve the issue. This is the first time in Bitcoin’s history that we are facing a “crisis” and we should properly negotiate to resolve it. We are looking for the best, less risky solution. But there is no way, the community is split again and continues to fight... which means more instability for the Bitcoin community and the market. There are enough fights now, but they are not helping at all. Any (contentious) hard fork would not only result in a split, but if we don’t implement it correctly and coordinate it in a timely manner, it could create two separate versions of the blockchain. This would be accompanied by a loss of Bitcoin users (including sensitive financial losses). We weighed all possible scenarios and considered the risk of a worst-case scenario where more than 50 core developers could leave the project. Our goal is to find consensus and execute a coordinated soft/hard fork. We believe we can create a win-win situation, rather than instability. After the vote, we should unite around one version, which is the more democratic way. We also agree to review any future hard forks and to avoid additional hard forks. In order to restore stability to the Bitcoin market, we must act collectively and quickly to stop this trend. We have held meetings to discuss how to resolve this impasse, try to find a more balanced solution, and drive progress. What is urgently needed now is an inclusive roadmap that takes into account the needs of businesses and communities and reduces uncertainty in future markets. Bitcoin is powerful and transformative, and together we will ensure its future is bright.
KnC: Sam Cole I'm all for compromise. So, what I can do is not deploy classic nodes or mine any classic blocks for two weeks. Let's give them another chance. I will sign this letter and I will agree to keep my mouth shut for two weeks and not lobby for classic or any other fork. After that, I think we need to be tough with them a bit until they give up, or we separate Bitcoin from them, everyone on this list wants more than just Bitcoin to survive. And I feel like, with the current core team, we are in anything but survival mode. A clean house is often a good thing.
Alex Petrov, Bitfury: Stephen, we understand your point, but it seems you are getting off topic. We are discussing here in the hope of finding a win-win consensus rather than creating any division. We are looking for and exploring many ways to reach consensus. Core tested Segwit in December 2015 and completed most of the testing. They also plan to release more features. Of course, isolated verification is not the final solution, but it allows the expansion effect to reach up to 4Mb. 1.core can also make a 2Mb hard fork in the short term, and it may be more professional.
2. Classic was announced on March 1, 2016, core was announced on April 1, 2016, and it was planned in advance in October 2015 (so you felt that 1 month would make a big difference, and that the "very quick and easy test" of classic was an appropriate decision)
3. We have implemented more than 20 different technology source codes such as core, classic, etc. This is not just our preference choice.
4. Choosing "classic" may mean losing 50-150 core developers forever. Classic uses 99.95% of the core source code, which is not a good choice.
5. When we can formally plan the hard fork, we may even combine the two parties, or classic will be merged into the core development team. In order to avoid misunderstandings in the community, we agree on the relevant dates and make them public. The risk of splitting the blockchain into two chains is still too high, and it will damage Bitcoin.
6. Of course, cores are not perfect either, they also have problems, such as problems with public and communication, they do not achieve transparent delivery and so on. PS: Please also check out the diff/pulls of classic, there is a lot of code that is not written by Gavin/Jeff. Hard forks are also risky because from a development perspective, Gavin+Garzik+Toomim cannot compare to 300 developers. Of course, please don't take my short article as a preference for core or classic. We support balanced and objective solutions that are less risky and most effective. Now, we should come together to make a final statement, which has been discussed a lot before, and this statement should be released this week to provide clarity and stability to the community and the market. All the negative fights and negative posts have brought bad effects. You may sign this statement or choose not to sign it; it is your decision.
Stephen Pair, CEO of Bitpay: Samson said that Segwit is a safer solution. I don’t agree with this view. Segwit is a very dangerous change that requires a lot of code changes. Although it may be a good idea, it will take time. I expect Segwit to take a full year or two to deploy. Bitcoin can and will scale, even beyond the capacity of traditional payment networks. It will not compromise the decentralized integrity of the system. At BitPay, we choose the fork that shows the most promise for the future in terms of scalability, because we believe any other fork will be eclipsed and eventually die. It is based on a simple economic prediction. The fork with the lowest fees and the most performance will win. It is imperative that the mining community figure out how to move forward. You have invested a lot of energy and financial resources in maintaining the security of the Bitcoin blockchain. You need to take steps to secure this chain and keep this mining algorithm viable. It is entirely possible that your users will abandon you and choose a fork with a new mining algorithm. In addition, some people who have invested very little in Bitcoin may benefit from a crash or reboot of the system rather than trying to protect it.
bitpay Stephen Pair: I think this is a good open letter, but I don't want to sign it. I appreciate it and thank you for your efforts. Although I think you are exaggerating the number of developers involved in the (core) project (remember, I have been very closely involved in Bitcoin since 2010), I really hope your persuasion efforts will be successful.
Smartwallet Dino Mark A: Brian, Stephen and other trading operators. I'm curious, have any of you run a scenario like this: what are the risks when a major mining pool or miner changes their mind at the last minute and runs a fork? Let's say 75% of the hashrate votes for Classic to succeed, but during the 28 day grace period, some miners change their mind and continue running core. When the block is triggered, to everyone's surprise, we have a 50/50 split. Now, Coinbase accepts BTC on the Classic fork to pay customers in USD, and if this fork fails, Coinbase is stuck with worthless BTC. The same scenario applies to other exchanges/payment processors. Without a legally binding agreement between miners and mining pools, will they continue to mine on a specific fork? From a legal and regulatory perspective, who is responsible for potential losses to payment processors, exchanges, and merchants? Is it a specific group of miners that is responsible? I raise these questions because there is no open forum in the industry to collectively review the pros and cons of various scaling approaches. All I see is a deep split (see Barry Silbert’s tweets https://twitter.com/barrysilbert/status/694911989701861376 and this http://bitcoinocracy.com/arguments/if-non-core-hard-fork-wins-major-holders-will-sell-btc-driving-price-into-the-ground) over what is safe and what is not. Yes, if we delay scaling, it will hurt user growth. However, if we continue to fork, which will result in the loss of money, do we know that it will cause long-term damage to the Bitcoin brand? Are we all used to fighting to see who will win the battle? What signal does this send to the broader financial markets? What kind of foundation would want to hold a crypto asset that is uncertain about every upgrade? Worse, we already see competitors rising up on coinmarketcap with smoother development processes, including pre-made hard forks. They have a higher-level multi-scripting language called solidity that allows developers to easily create smart contracts. Bitcoin is stuck in clunky opcodes, most of which are banned. Here we are arguing about 2MB blocksize and more issues for us to worry about. And competitors are just watching and learning from it. We are missing the big picture. As a founder, I understand the importance of users and rapid expansion, and I also know the pressure VCs put on companies. On the other hand, if the CNBC headline is "Bitcoin exchanges suffer losses after hard fork upgrade", we will be collectively poisoned and my investors will suffer losses. I support the 2MB hard fork, we need it. If Core doesn't come out with a scalability solution in a reasonable amount of time, I will switch to a safe alternative. However, as an industry, we should take a thoughtful, data-driven approach before choosing another path.
Brian Armstrong, CEO of Coinbase: Philip will try to explain this. If you have 3-4 different nodes all using the same protocol, they can upgrade individually or in groups. If a certain threshold is reached (70%?), the network will upgrade (any nodes that don't support it will rush to switch to this network, or their clients will switch). Therefore, if you have a diverse set of nodes, protocol upgrades and consensus rules will still work, similar to web browsers and web standards. Hopefully this helps a little. Dino, I don't think what you wrote is possible. A minority fork (whether it's 30% or 49%), it will last no longer than a few hours I think. The risk for miners is that if you don't mine the longest chain, you will lose the 25 BTC. So, miners will quickly flee the losing chain (a 50/50 split is like an unstable molecule, where 50% of miners will have zero income, they will eagerly guess which side will win, so they will join the other side).
BTCC Samson Mow: Over the next two weeks, we need Bitcoin Core developers to work with us to explicitly include a future hard fork in the scaling roadmap in addition to SegWit. We will not run a Classic node on production systems, or mine any blocks on a Classic node, until we find the best path forward. We ask that everyone act with reason and hold off on making a decision to run a contentious hard fork (Classic/XT or any other). If Bitcoin Core still does not agree to scale in this way, with an activation date in the next 12 months, we will likely need to find new leadership to implement the hard fork.
| 
