分岐まとめ

2017-07-21

関連するフォークは以下のものがある:

Segwit or BIP141. BIP9 の手順でデプロイされる。
Segwit2x. BIP91 の手順でデプロイされる。
UASF. BIP148 の手順でデプロイされる。
BitcoinCash or BitcoinUnlimited or UAHF. http://www.bitcoincash.org/ の手順でデプロイされる。

Segwit and BIP9

sigScript を tx から分離する仕様(BIP141).

デプロイ手順は BIP9 で、bit は 1, 期間は 2016年11月15日から一年間。 BIP9 は、チェーンブロックを 2016 毎に区切り、あるブロック群の状態は直前のブロック群の状態によって決める。

直前のブロック群の 1916 ブロック(95%)が指定の bit を立てていた場合、ロックイン状態とする。
直前のブロック群がロックイン状態の場合、アクティブ状態とする。

要するに、2016ブロック群中の95%が bit を立てていたら、さらに2016ブロック経過のちにアクティブになる。

UASF and BIP148

bit1 が立っていない(正確には3,2,1bit が 001 ではない)ブロックを無効とする。必然的に 100% のブロックで bit1 が立つので、Segwit がデプロイされる。

デプロイは 2017年8月1日から 2017年11月17日のフラグデイ方式。正確な開始時刻は unixtime 1501545600 = 2017-08-01T09:00:00+09:00 このタイミングで Segwit deploy がロックインまたはアクティブ状態で無い場合に発動する。

Segwit2x and BIP91

BIP148 と同様に、bit1 が立っていないブロックを無効とする。

デプロイ方法は BIP9 に似て、336ブロック中の 269ブロック(80%)でロックイン。フラグは bit4. 期間は 2017年7月1日から2017年11月15日。

BitcoinCash

ハードフォーク。有効なブロックサイズを 1MB超8MB以下にする。さらに新たに SIGHASH_FORKID(=0) を追加しリプレイ攻撃を防止。

デプロイは 1501590000 = 2017-08-01T21:20:00+0900 のフラグデイ。

状況

http://bitcoin.sipa.be/versions.html

2017年7月20日現在、 Segwit (flag1) は 45% ほどで、このままでは達成の見込みはない。 Segwit2x (flag4) は 80% に達し、現ピリオドでロックインの可能性高い。 UASF は、8/1までに Segwit ロックインされないので、UASF ロックインの見込み。 UAHF は Jihan の言動より発動の見込み。

より精確な日付を調べる。 https://blockchain.info/ja

2017-07-20 12:46:15 UTC(=@1500554775) に 476700 ブロックが掘られている。 https://blockchain.info/ja/block/000000000000000000bd6ed8a9f5f2b1f2708e8c7eefb33a14ba95726bbf0810

336ブロック期間の始まりは、476784, 477120, 477456, ... となる。同様に 2016 ブロック期間は、477792, 479808, 481824, ... 1ブロック10分として、各ブロックの時刻を予測すると、

%336	%2016	unixtime	JST
476784		1500605175	2017-07-21 11:46:15
477120		1500806775	2017-07-23 19:46:15
477456		1501008375	2017-07-26 03:46:15
477792	477792	1501209975	2017-07-28 11:46:15
478128		1501411575	2017-07-30 19:46:15
		1501545600	2017-08-01 09:00:00
		1501590000	2017-08-01 21:20:00
478464		1501613175	2017-08-02 03:46:15
478800		1501814775	2017-08-04 11:46:15
	479808
	481824
	483840

まず Segwit2x だが、現ピリオドで 80% を占めれば、7月21日にロックイン、7月23日にアクティブになる。現ピリオドで未達であれば、次のピリオドに順にずれる。

仮に現ピリオドで Segwit2x が有効になっても、Segwit の現行ピリオドで flag1 を 90% にするのは無理。次の Segwit ピリオドは block 477792 およそ 7月28日から始まり、この期間が終わってようやくロックインになる。ところがこの期間中に UASF のフラグデイ 8月1日が含まれるので、Segwit2x の状況にかかわらず UASF が発動することになるだろう。ただし、Segwit2x が発動済であれば、Segwit2x ノードと UASF ノードで動作は同一になる。まとめると、発生するフォークは、 Segwit2x がアクティブになった時の Segwit2x と現行チェーンでのフォークのみになる(UAHFは除く)。

Segwit2x のソフトフォーク

Segwit2x のみがアクティブになっている場合、

Segwit2xノード: flag1 の立っていないブロックを拒否する(flag1チェーン)
非Segwit2xノード: flag1 に関わらず受け入れる(coreチェーン)

という二つのチェーンが並び立つ。 flag1 ブロックは両方のチェーンで有効であり、非flag1ブロックはcoreチェーンのみで有効になる。非Segwit2xノードからすると有効な二つのチェーンがある状態になる。 coreチェーンが長い状態から flag1チェーンが長くなった場合に、flag1チェーンがメインチェーンに格上げされ、coreチェーン上の取引が無かったことになるリスクがある。また、チェーンが並立している状況だと、どちらのチェーンもリプレイ攻撃を受けるリスクがある。

ブロックの流通が十分で、かつ Segwit2x ノードのハッシュレートが多ければ、coreチェーンよりも flag1 チェーンの方が長くなるので再構成は発生しないですむ。一応 Segwit2x が有効になるのは 80% が条件なので、彼らがそのまま Segwit2x を有効にし続ければこのような状況になるだろう。もし Segwit2x 側のシグナルが偽装の場合、flag1 チェーンと core チェーンの再構成が起きる状態になる。UASF が起きてもハッシュレートバランスは変わるが、やはり圧倒的な差が付かない場合は常に再構成が起きうる状態になる。

また、Segwit2x ノードが少数(ハッシュレートではなくてノード数)で互いに接続されていない場合も別の問題がある。非flag1ブロックが長くなると、新たに掘られたflag1ブロックは短いチェーンのものなので非Segwit2xノードは伝搬しない。孤立した Segwit2x ノードがどんどん新規ブロックを掘ってもそれは伝搬されず、そのノード固有のチェーンとなる。また別の孤立した Segwit2x ノードは独自のチェーンを延ばす。ハッシュレートは実質的にノード単一のものになるので、次の難易度調整までブロックがほとんど掘られない状態になるだろう。

UAHF

BitcoinCash は segwit が有効無効どちらにせよ core のブロックと互換性が無い。再構成の可能性は無く、完全に別のブロックチェーンとして扱える。

オプションでのリプレイ攻撃対策は用意されている。 UAHF チェーンのみで有効なトランザクション(SIGHASH_FORKID)を作る方法と、UAHFチェーンで無効なトランザクション(OP_RETURN に特定文字列を入れる)方法の二通り。 ※非segwitな通常のcoreトランザクションはUAHFでも有効なのかな？だったらリプレイされちゃいそうだ。

なお、分岐前に存在していた UTXO は、分岐後も有効である。ユーザーから見ると、分岐前の BTC と同額の BCC を保有した状態になる。