The reason why the price is going down is because we don't like the BU threat that will give the power over the blocksize to just 5 mining pool operators (or effectively 1 ASIC manufacturer.) I like bitcoin for it's decentralization properties, not because I trust Jihan Wu so much. I will never accept the idiotic idea called "emergent consensus."
Big blocks are great. I definitely want to see safely planned blocksize increase after Segwit. And if it won't be merged in the beginning in Bitcoin Core, I will just support another client, but emergent consensus is still a joke and Segwit is still the obvious way forward.
Others have said this before, and I think it is worth saying again. The support that BU is getting is not because the ideas behind BU are so great, it is because of the strong opposition to Core and SW.
I don't believe there are any SW features that are *
needed* today/now, but are rather features that might be nice to have in the future. Larger blocks on the other hand is something that Bitcoin has needed for years now. I don't see a reason why SW should get implemented prior to larger blocks, especially after what happened with the HK agreement.
Even if you don't like some Core developers, it should not be a reason to support a broken risky concept "emergent consensus" and to reject Segwit without any proper technical arguments.
I don't think there is necessarily a dislike of certain Core devs, I think it is more a dislike of Core as a whole, likely including their scaling roadmap.
I think the appeal behind EC is that it has shown to be very difficult to raise the max block size, even when there has been a reasonable argument (you may not agree with it) that the block size needs to be immidiately raised for the past two years, and EC removes the vast majority of the friction of raising the max block size in the future. I don't personally like EC very much, however I think it is better than the status quo -- I would personally like to see something along the lines of BIP 101, and if the max block size in BIP 101 turns out to be too fast, the max block size can effectively be reduced via soft forks.
In regards to SW, I believe I have read that it is something like 50,000 lines of code, which implies it is horribly complex (I am not 100% sure on this stat, although this fact is given little weight in my opinion), and it leads to things that will change the security model of Bitcoin. As it stands today, the miners receive ~all of the transaction fees, which is what gives them incentives to keep the network secure. By removing revenue from the miners, you are lowering the EV of a $1 investment in mining equipment to use to secure the network, and increasing the EV of a $1 investment in mining equipment to be used to harm the network (currently negative).
Some people have said that on-chain transaction will happen anyway, and happen today, for example when someone with a Coinbase account sends money to someone else's Coinbase account. This is true, however there is significant friction by doing this because of the counterparty risk, and because of the lack of privacy that this entails. SW (via LN) will reduce this friction by nearly eliminating the counterparty risk (there are still very real ways that a party acting maliciously could attempt to steal your money, and often be successful).
Segwit will give us effectively 2.1 MB blocks (if used.) If "Roger Ver" and "Jihan Wu" really cared about "more transactions", they could have Segwit activated in just a few weeks. Any blocksize increase by HF will take much longer than that - especially if you want to have a non-contentious HF (eg no blockchain split.) This should be enough reason to activate Segwit ASAP even if someone hates "Core" so much. We can just focus on a good dynamic blocksize increase with safe thresholds etc after that.
According to
coin.dance (I have some concerns about their reporting, but they will do for now), 28% of companies are not ready for SW, and an additional 5% are outright against it. Some who are "not ready" are probably against SW, but just don't want to say because they don't want to get involved in political disputes. As a result of this, I would consider SW to be a contentious fork, even if you want to sell it as a soft fork, which I disagree with (I actually have been recently unable to find any references to "soft fork" and "hard from" from days prior to Bitcoin, so I believe these terms, and definitions were made up by someone/some group within the Bitcoin ecosystem, and my understanding as to what a "soft fork" is has changed over the past couple of years, eg. I would give you a different definition of a "soft fork" in 2014, than what I would say that the devs consider a "soft fork" today, I am not sure if this is because my understanding of Bitcoin has improved, or if the devs have evolved the definition of "soft fork" over time).
At this point, I don't think that a contentious fork is avoidable when it comes to scaling solutions, at least not for the first step. I would be very surprised if anything that resembles consensus is reached for a scaling solution, especially the unrealistic high bar that many core devs, and other prominent players have said is necessary.
In my opinion second layers like the Lightning Network are very cool too and will be much easier with Segwit too. Buying coffee was never really feasible with bitcoin, not because of the fees, but because of the slow blocks (10 min avg, but frequently 1h.) LN will not just make micro-transactions very cheap, but also allows them to be instant. Of course it would still take years before we can really use this, but if we could at least test it on mainnet already - progress will probably go even quicker. Note that there are already 6 different LN implementations:
Amiko-Pay,
Eclair (ACINQ),
lightningd (Blockstream),
lit (MIT Digital Currency Initiative),
lnd(Lightning Co),
Thunder (Blockchain.info) - some of them work already on testnet. While I still have many skeptical questions about LN, it does seem nice for small (low-value) payments.
I stated my primary concerns about SW (and in turn LN) above.
In 2014, it was generally safe to accept a 0/unconfirmed transaction, as the rules to determine if a transaction would confirm were fairly clear, and would not change (for the most part) from block to block, so you could look at the majority of unconfirmed transactions that you receive and say that it will either confirm within a few blocks, or that it will not confirm at all, and would usually be correct. There were multiple gambling sites that would display the result of an on-chain bet prior to the transaction/bet being confirmed, and the losses due to double spends were low enough so that they continued offering this service. Today, the criteria of if a transaction will be confirmed within the next few blocks changes from block to block and will mostly depend on recent transaction volume and what is in the mempool, however the advent of RBF further complicates this.
Accepting a 0/unconfirmed transaction (assuming there is sufficient block space) is not all that different from accepting a check or a credit card payment, as the risks are very similar. Some people have claimed that transaction fees will move towards zero if the max block size is too large, however this can be resolved by making transactions that include a fee of under
x BTC/byte outright invalid, and in order to account that an acceptable fee rate might change over time, this can be done via a series of soft forks (eg have a soft fork that says that any transaction confirmed in blocks 500,000 through 550,000 that contain a tx fee of under 100 sat/byte are invalid, then around block 500,000 a new soft fork could be implemented that says any transaction confirmed in blocks 550,001 through 600,000 that contain a tx fee of under 98 sat/byte are invalid, and so on). If this was implemented, then the block size could be set so that the mempool is effectively cleared when each block is found.