As you have all likely heard there is a debate going on now in Bitcoin. Many people have been talking about it for many months. It has created, and still continues to create, news and work for all those involved. I thought I would let everyone know some of the issues from a miners point of view.
SegWit or HF (2 MB Hard Fork)
Those appear to be the only near term solutions we have available to us right now. By that I mean the other solutions I have seen proposed are further away and less is known of them. Rather than just simply point out which one of those two solutions I am supporting I will add a bit of detail as to why I am supporting them in the form of a comparison.
The headings for my comparison will be as follows:
Development process, Testing process, Deployment process.
Potential impacts, likely impacts.
Potential issues, likely issues.
Spam resilience.
Development process
Segwit:
The developers behind this suggestion are very well known. I have faith in the fact that Segwit will work from the protocol side and be of the highest quality when it’s released. My concern is that the approach will require all of the wallet providers and anyone that interacts with the core software to directly alter their software to take advantage of this update, and here in lies my concern: It means all of the developers that have any transaction interacting code will need to alter it. So while it’s a soft fork for bitcoin it’s a hard piece of work for many, many others.
HF:
A HF is from a development point of view again a simple code update of the protocol, with no major (in most cases minor) changes to other systems.
Testing process
Segwit:
Testing SegWit in production can only really happen after miners have activated the soft fork. This adds to my concern that it will take longer to revel it’s true benefits.
HF:
It’s a hard fork. there are not any real possibilities to test it before it goes into production at all. I believe that it should contain the least amount of changes possible to mitigate any issues.
Deployment process
Segwit:
The current proposal is a soft fork. This method has been proven in the past and has worked many times I see no technical issues with the deployments as long as there is no hold up from miners. Some previous hotfixes (softforks) have taken many, many months to be activated by miners.
HF:
Deploying a hard fork is not a decision that should ever be taken lightly. After all its an upgrade to the network that everyone must take part in. My theory is that with good communication and a timeline that everyone can follow it can actually be a community occasion. It’s not without risk, but it has been done before and it will need to be done in the future for most of the real scaling solutions.
Potential impacts
Segwit:
Segwit has a potential of around 1.6x the number of transactions in the current block size. This number grows depending on the type of transactions people create.
HF:
This is linear but the most spoken about HF is to 2 MB, effectively doubling the current max throughput.
Likely impacts
Segwit:
This is one of the main points I want to make. I believe its likely impact will be near 0 in the short term. It’s voluntary, people don’t have to use it. Its 2016, we are lazy people, lets face it. So when you have developers out there who have to release an update to a piece of software to be nothing other than nice to everyone else, it takes time. It just does.
HF:
The likely impact from the HF is that the throughput will be available at the max block size. for example a 2 MB bump will make available 2 MB of transaction space.
Potential issues
Segwit:
The biggest issue I can see here is that it’s impact will be low. In fact I think very low. It simply won’t solve anything. The network will still be slow the transaction volume from the same sources will continue to grow not taking advantage of the SegWit space. We will be back to where we started before long.
HF:
The deployment is a biggest issue here as detailed above.
Spam resilience
One of bitcoins most valuable features is that, like email, it’s permissionless and, like email, it lends its self to spammers. I don’t like email spam and I don’t like transaction spam. There are however different types of bitcoin transaction spam. The type that are low value transactions (dust) where people add a message to the transaction begging for bitcoin etc. Believe me, as an operator of large wallet balances these do happen often. Then there are the other types of spam: The spam attack. These are the ones I want to concentrate on. Simply put the user sends bitcoins to himself/herself filling the blocks up. with blocks at near full capacity now, its not that hard to do. These attacks cause a serious issue when they are ongoing. So how will each of the two suggestions cope with the spam attacks.
Segwit:
The spammer will take the easiest and cheapest way to fill the blocks. I don’t think anyone will disagree with that statement. With little impact from segwit the spammer will have an easier job than today. The blocks will continue to fill up as they have been with non-Segwit transactions. The pressure from the normal transactions will effectively produce the same issues as the current spam attacks. So all a spammer will have to do is nothing. the network will produce his/her desired result on its own. It will be like being under a constant spam attack.
HF:
Lets take 2MB as the block size here. If an attacker has to fill 100k of blocks today and wants to spend 40,000 USD doing it. (yes that's how much they have been spending on spamming bitcoin) To achieve the same thing on a 2MB block size they would have to submit the same 100k (until we naturally go over the 1MB limit, which will happen soon). Then another 1MB (lets call it 1000k for easy maths) meaning to produce the same result it would cost 440,000USD. Now that's expensive spam.
I think my conclusion is obvious: A HF done carefully will be more successful and offer more potential.
So with my comparison above showing that while Segwit, with an elegant solution and a simpler deployment solution, is a nice idea, is just not going to be enough. Add to that the conflict of interest which developers have, and it’s not hard to see why we have chosen Bitcoin Classic as the way forward. It have an excellently run team with good principles behind them. No conflicts of interest and a willingness to produce some simple code to simple problems.
This blog has gone on enough now. I will write more in the future on these two solutions. Something tells me with the players in this space so far apart from each other, I don't think without a major shift things will change fast.
