---
## *Bitcoin __will__ fork. Two communities with different ideologies should and will evolve independently. With the August first deadline, it will happen soon. Whose propaganda should you follow?*

---
![](http://i.cubeupload.com/zNRUcZ.png "Bitcoin and hardfork")

---
## There was an agreement in New York?
[During Consensus 2017](https://medium.com/@DCGco/bitcoin-scaling-agreement-at-consensus-2017-133521fe9a77), a group of prominent Bitcoin figures representing 83% of the network hashrate agreed to implement the following in Bitcoin:
- Activate Segregated Witness at an 80% threshold, signaling at bit 4
- Activate a 2 MB hard fork within six months

These were unofficial terms set by some miners that basically boil down to: SegWit now, we will get around to a hardfork block size increase at some point. Although an agreement was formed, these signatories are only signaling their intent, there is nothing binding anyone to any particular choice - especially the 2MB hard fork that is supposed to happen around the beginning of November. 

The problem with this whole fiasco is that after SegWit activates, there is nothing enforcing the future blocksize increase. After SegWit activation in the current SegWit2x proposal, the 2x part will undoubtedly be rediscussed and argued over. Signaling does not fake a hardfork.

I am not going to describe the web of potential signaling bits and differences between UAHF, UASF, Segwit2x, etc.. I really recommend visiting Bitmain's [page](https://blog.bitmain.com/en/uahf-contingency-plan-uasf-bip148/) detailing their UAHF contingency plan. Jimmy Song's [article](%20https://medium.com/@jimmysong/segwit2x-what-you-need-to-know-about-the-2mb-hard-fork-27749e1544ce) and the [diagram below](http://www.adesblog.com) help to outline some of the behavior implemented by current production code regarding the imminent chain split. 

![](http://i.cubeupload.com/lEtaMQ.png "SegWit is not a blocksize increase")

`edit: replaced chain diagram for more accuracy.`

Notably, there are some that have voiced their intent to never accept a SegWit transaction and hardfork to a large-block and SegWit-free chain. See [www.bitcoinabc.org](www.bitcoinabc.org). Does this position make any sense?

## Is SegWit Bitcoin?
SegWit is touted by many Bitcoiners as the "best tested scaling solution" and "has been tested for over a year", both in stark contrast to the iterated 'dangers' of a hardfork. Myself and many others argue that the shift in incentive structures caused by SegWit are dangerous and *not fully understood.* See [discussions by Peter Todd](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012103.html). SegWit Bitcoins might not have the same value properties as Bitcoins - fundamentally breaking fungibility, a key property of Bitcoin. 

- The argument is not that transaction malleability should not be fixed. - it should be. 

- The argument is not that all scaling should be done on-chain. - it shouldn't be.

- The argument is not against the softfork format anymore. Hardforks can be safer but there is nothing wrong with a uncontroversial softfork. 

- The argument is not even in the anyone-can-spend update mechanism.

- **The problem is with SegWit itself.** - the problem is in SegWit's implementation. 

Bitcrust, a new Bitcoin implementation that uses a unique modular approach and parallel verification mechanism to allow high transaction throughput, has published a clear blog post detailing the dangers of SegWit signatures. I recommend a read if you want to know why I make the claims herein.

#### [https://bitcrust.org/blog-incentive-shift-segwit](https://bitcrust.org/blog-incentive-shift-segwit)

<br>

In short, SegWit can flip the incentives for some (bandwidth restricted) miners such that they benefit from not downloading or verifying the transaction signatures. For a user, this causes a SegWit transaction to be less secure than a non-segwit one. A non-SegWit transaction is secure with the assumption that no attack is able to obtain more than 51% of the network hashrate. With SegWit, this becomes 51% - (percent of miners with flipped incentives). 

If 20% of miners end up in a situation where they are not downloading signatures because it is more profitable for them not to, a 31% miner can attack the network effectively. Security becomes 51% - X. 

The bigger problem is that it is very hard to estimate the proportion of miners with this flip in incentives before their portion grows too large and an attack occurs. This basically means that SegWit transactions will always be less secure than normal Bitcoin P2PKH transactions. Even if just by the smallest bit, this is what fundamentally breaks the fungibility of Bitcoin. 

Read more [here](https://www.reddit.com/r/btc/comments/6ktqrh/did_hell_just_freeze_over_peter_todd_small/).

What do I support? Well, I like simple hardfork malleability fixes like [this](https://github.com/tomasvdw/bips/blob/master/malleability-fix.mediawiki) or even the BIP140 softfork. I also support the groups who will be maintaining both Bitcoin ABC nodes and running pools that do not accept SegWit transactions. Fundamentally, I support Bitcoin as designed by Satoshi. 

#### But with SegWit, the Lightning Network will solve all our scaling woes
No. No it won't. 

[It mathematically can't.](https://www.youtube.com/watch?v=MMNfBOUUvgM) 

Lightning Networks can *always* be [Sybil](https://en.m.wikipedia.org/wiki/Sybil_attack) attacked. 

This does not mean that the Lightning Network (LN) will be useless. There will certainly be many applications and uses for payment channel systems. They will not be used for everything.

The solution is not SegWit now, then move all scaling to layer two solutions like sidechains and the LN. That is just the solution that Blockstream wants so their products will have value in the first place. 

## Radical On-Chain Scaling
Many long-time Bitcoiners and miners are supporting the continued extension of a SegWit-free chain come the August first chain split. The consensus is that this chain will experience the blocksize increases we have desperately needed via hardfork. 

[Bitcoin ABC](https://www.bitcoinabc.org) represents one of the codebases that implements a radically adjustable blocksize cap. 

Clean hardforks are a much better scaling solution than anything proposed thus far. A hardfork is the *only* safe way to deal with a controversial change.   

## Moving on
The greatest thing that this UASF movement has brought to Bitcoin is the August 1st deadline. Ethereum has ice ages, what does Bitcoin have? Decentralized communities need definite deadlines to rally behind. The August first deadline is forcing the members of any Bitcoin ideology to have a plan in place for a chain split. 

What will different clients enforce? 
What client implemented your ideology? 
Where are my coins located? Do I possess my private keys?
These are questions for you to sort out yourself. Make sure you own your own public keys so you can make a choice in the future. 

Two communities with different ideas should evolve independently. 

The beauty of open source software is that it only stays around if people want to use it. - it becomes whatever is useful to its user base. 

The 35 billion dollar question is what chain will be the Bitcoin (tm). I hope this chain gets bigger blocks and thinks long and hard about implementing SegWit. 

---

I hope this helps you see through some of the propaganda. Comment your Bitcoin scaling opinions below.

Stay decentralized, 
Kyle

---
![](http://i.cubeupload.com/FYcGgR.jpg "SegWit a blocksize increase ")