ビットコインのETFが非承認になって、とりあえずしばらくの間はスケーラビリティ問題に話題が移りそうです。ということで、Bitcoin UnlmitedとCoreの対立についての簡単なまとめと私見を書いておきます。
Bitcoin Unlimited
Bitcoin Unlimitedとは、ビットコインのブロックサイズ上限1MBを撤廃して、ダイナミック（可変的）にブロックサイズを決定しようとするソフトウェアのバージョンです。「公式」のソフトウェアはBitcoin Coreと呼ばれており、その開発チームとは別の人々によって立ち上げられました。
現在のビットコインのブロックは、もうだいぶ前から1MB上限に達しており、最近は特に混雑具合が増して必要手数料が増大する状況になっているので、すぐにでもブロックサイズを上げなければならないという観点等から主にBitcoin Unlimitedの支持者が増えています。
現在はSegwitをソフトフォークによって実装するプロセスが実行中ですが、Bitcoin UnlimitedはSegwitに否定的であるというのが特徴です。その理由は、ソフトフォークはハードフォークよりも複雑だとか、Segwitやその後のLightening Networkによりマイナーの手数料が減るとか、SegwitはBlockstream社（サイドチェーンなどを開発するCore開発者の何人かが所属するブロックチェーンの開発企業）の商品でSegwitが実装されればBitcoinはよりBlockstream Coinになってしまうとか様々なことが言われています。
正直なところ個人的にはSegwitの否定的な意見に納得できるところはほとんどなく、政治的な道具になってしまっているという印象です。
また、Bitcoin Unlimitedは技術的にも以下のような危険性が指摘されています。
Bitcoin Unlimitedの設計哲学「突発的コンセンサス」が危険な理由 | ビットコインの最新情報 BTCN｜ビットコインニュース
この件を含め、開発チームの開発力にも疑問があり、公開の定例ミーティングなども一切やっておらず、Coreの開発チームと比べると相当レベルが下がるのではないかという印象です。
そんなわけで、ダイナミックなブロックサイズ変更という根本思想一点には賛同できますし、Coreは現状を見ていますぐブロックサイズを上げるべきと感じます。ただし、Bitcoin Unlimitedにはその他で納得できるところがほとんどないので、Coreのほうが好ましいと思っています（日本には「Unlimited派」の人がほとんどいない気がするので、意見を発信してくれると面白い。）。
Segwitも持ち上げられすぎ？
同時に感じているのがSegwitが持ち上げられすぎではないかということです。「Core派」の中には、Segwitによりブロックサイズ上限が実質的に約2MBまで上昇するので、ハードフォークによってサイズ上限を引き上げるのと同じ効果だから、とりあえず賛成に回れという人もいますが、実質的に約2MBというと（当ブログ記事でも過去に書いてしまいましたが）語弊がある表現になってしまうかもしれません。
というのもSegwitを利用するには新しいアドレス形式（マルチシグネチャと同じ3からはじまるアドレス）を利用しなくてはならないからです。Segwit実装後も、もしすべての取引が現在の1からはじまる普通のアドレスや3からはじまるマルチシグネチャアドレスのみから行われれば、ブロックサイズ上限は1MBのままです。
一般のユーザーがSegwitの新しいアドレス形式を理解して、広く使われるようになるにはかなり長い時間がかかるものと思われます。このため、Segwitが実装されたらすぐに手数料が元に戻って安くなるというのは楽観的すぎる見方かと思います。
また、Segwitはトランザクション展性を根本的に修正するのが主目的ともいえるものですが、同様に新しいSegwitアドレスを利用しなければ全く意味がありません。今までの1からはじまるアドレスには引き続きトランザクション展性が存在し、何回かソフトフォークによって修正対応はされており「Segwit待ち」のソフトフォークによる修正計画（BIP146）も現在あるのですが、今後も新たな脆弱性が見つかった場合には都度修正する必要があります。
UASF
さらに最近もう一つ話題になっている「UASF」というものがあります。これは、User-Activated Soft Forkの略です。そのまま訳すと「ユーザー主導のソフトフォーク」的な意味になり、語感から言うとノードの賛成比率からソフトフォークを実行するの？と勘違いされがちですが、全く違います。
別の言い方として「Flag-day soft fork」と言われることがあり、こちらのほうがより正確です。要するに、特定の日になったらマイナーのハッシュレートにもノードのアップグレード率にも関係なく強制的にソフトフォークをしようとするものです。マイナーのSegwit賛成率がなかなか上がらないので、ユーザーが賛成すればSegwitを実装できるようにしてしまおうという考えが背景にあります。
このUASFは、なぜかCore派の代表的主張として取り上げられることが多いのですが、最初の発端は「shaolinfry」という匿名の人物がビットコイン開発チームのメーリングリスト及びbitcointalkに投稿したことであり、Coreの開発チームから話が出たわけでは全くありません。
実際的にUASFについては、Coreの開発チームはほとんど無反応という感じです。「Core開発者」の範囲をどこまで広げるかにもよるのですが、広い範囲でいうと正直誰がそうなのかほとんど把握していないので、IRCの定例ミーティングに毎回出席しているような「コアな」Core開発者に限って言うと、Luke-jrが低いマイナーのハッシュレート下では実質的にハードフォークとなる危険性を指摘し、75%程度のハッシュレートを必要条件としたほうが良いという提案（＝つまり今のBIP9ソフトフォークの閾値を下げるだけ？）をメーリングリストやredditでしています。その他、gmaxwellが「興味深い提案だけど、何か意見を言うのは時期尚早。いろんな意見が出るのはいいこと。」とredditで発言するにとどまっています。
その他、「Core派」の普通のユーザーの中にもUASFによるフォークの危険性を指摘する人が多くいて、本当に本気でUASFを実行したいと考えている人が多いのかは疑問です。
また、実はUASFの考えは新しいものではなく、Nakamoto Satoshiが開発していた時代のソフトフォークは、まさに特定の日が来たら強制ソフトフォークを実行するというUASFとほぼ同じ考え（UASFはBIP9のソフトフォークプロセスを前提としているので厳密に言えば違います）のものでした。
その後、安全性・安定性の観点からBIP16でハッシュレート55%を閾値とし、BIP34でFlag dayを撤廃したうえでハッシュレート75%を閾値とし、さらにBIP65,BIP66では95%を閾値として、現在のBIP9の複数段階のソフトフォークプロセスに移行してきたという経緯があります。正直なところ、過去の仕様に戻すようなUASFがなぜこんなに話題になっているのか謎ですし、Coreの開発者たちの思想からいって実際に行われる可能性は限りなく低いのではないかと思います。
あったとしても、急進的な別グループがUnlimitedと同じような感じでフォーク版を作るということにしかならない気がします。
最も良い今後のシナリオは？
Bitcoin UnlimitedがCore側と和解してSegwitも採用というのが万々歳な未来ですが、今の状況を見ているとなかなか一筋縄ではいかなさそうです。よくCore側とUnlimited側が決裂してハードフォークというのが最悪なシナリオと言われますし最近まで自分もそう思っていましたが、むしろ膠着状態のまま何もできないのが最悪なのでは？という気がしています。
もしUnlimited側がハードフォークすれば、（中立の立場のマイニングプールがいないという条件のもとでは）Core側のチェーンにSegwit反対派がいなくなるため95%を自動的に達成し、CoreチェーンにSegwitが実装されることになります。同じ理屈で、Unlimited側でハードフォークを意図的に行わなくても、低いSegwit賛成率では危険なので難しいですが、もし90%程度まで達するのであれば、Unlimitedブロックを無効なものとCore側のマイナーが判定することで、強制的に95%へもっていくことも可能です。
実際にハードフォークが行われれば、ハッシュレートの低い方のチェーンは消え去るというある意味楽観論もありますが、やはりETHとETCの例を見ていても二つとも少なくとも短期的には生き残るのではないかと思います。ハードフォークにより価格は恐らく大暴落するでしょうし、ETHとBTCはさすがに規模が違うので取引所の対応やユーザーの対応はとんでもなく大変になるでしょうが、このまま何年も膠着状態を続けるくらいなら、いっそ長期的に見れば早く（Unlimited側が）ハードフォークしてくれたほうが良いのでは？というお話しでした。
参考サイト
[bitcoin-dev] Moving towards user activated soft fork activation
Version bits extension with user defined activation · GitHub
