these are protocols used for changing the bitcoin network protocols のプロトコルである）

these are pro.to.cols used for chan.ging the bit.coin net.work pro.to.cols

食事する哲学者 5人のミュート哲学者は夕食を食べるために5本のフォークを持っている。 彼らのスパゲティを食べるためには2本のフォークが必要。 シェアの方法は？ 並行処理の管理を証明するために利用する。

食事する暗号作成者 3人の暗号作成者は夕食を食べる。 ウェイターはその請求書が 彼らの誰かまたはNSAによって支払われていることを伝える。 NSAからのごちそうをもらったか公開せずにグループの誰かが払ったのは分かれる？ 暗号のプライバシーの管理 を証明するために 利用する。

食事するビットコイナー 3人のビットコイナーは ピクニックをする。 テーブルの上にフォークが無いことが気づいた。 皆が賛成する食器を選ぶ方法はどうするか？ プロトコルの変更の管理 を証明するために 利用する。

「フォーク」は何ですか？ リナックス 仮想通貨 何でも好きなコードを実行できる パッチを使うためにマスターにマージされる必要は無い Linusを納得させるために辛辣な議論が必要 全員が同じコードを実行するべき パッチをマスターにマージして動かす必要がある 世界を納得させるのはもっと辛辣な議論 リーダーは居ない

Bitcoinの基本フォークの種類 ハード フォーク ソフト フォーク 破壊させる変更であり、 すぐに全ネットワークの関係者がアップグレードするべき。 例：ブロック・サイズは2MBに拡張 後方互換性の変更であり、現在のルールの上にのせる新しいルール。 例：ブロック・サイズは0.5MBに減少

フォークの良い点/悪い点 ハード soft + より良いコードのクオリティ 中央的な判断と決定 全員を納得させることが出来ない もっと変更があればもっと口論が出てくる より悪いコードのクオリティ + 全員が最新バージョンを 　実行するのは保証出来ない 「クローズド・ソース」　の　変更？ + もっと少ない変更なので、 　口論はもっと少なくなる

altcoinの解決 tezos stellar ネットワークはコード変更互換性をチェックする機能が入っていて、シンプルな投票システムも入っている「nomic」。 「ブロッキング・セット」の間にネットワークのコンセンサスがあり、そのノードたちは前進を止めることができる。 ブロッキング・セットは強制的にプロトコルのアップグレードを実行させる。

Bitcoinのソフト・フォーク

nop  verify upgrades `OP_NOP<N>`  `OP_CHECK<t>VERIFY` 例えば SHA3 を追加したら： `<x> <SHA3(x)> OP_CHECKSHA3VERIFY`

segwit `0 <h(x)>`  v0でスクリプトxを実行する アップグレードのとき `1 <h(x)>`  v0でスクリプトxを実行する (v1なければ、ずっとtrue)

ソフト・フォークはどう作られたのか？

ブロックの高さ h が超えたら、新しいルール 高さにより ブロックの高さ　h　が超えたら、新しいルール

bip9: versionbits Bitcoinの32-bitのバージョン・フラグを利用して、同時ソフト・フォークをデプロイする ソフト・フォークは名前、ビット（0-28）、スタート・タイム、とタイムアウトを持つ 先行する2016ブロックの95%がビットを設定していることを確認してください

Versionbitsはどこが間違えたのか？

小さな誤解 大きな論争

BIP9は「準備が整った」の信号であるはず 「賛成」か「却下」の投票ではない signaling 対 voting BIP9は「準備が整った」の信号であるはず 「賛成」か「却下」の投票ではない

ソフトフォークはBIP9に入ったら デベロッパーたちは「実行する予定」と想定する signaling 対 voting ソフトフォークはBIP9に入ったら デベロッパーたちは「実行する予定」と想定する

しかしマイナーたちは違う考えを持つ 「賛成」と「却下」の投票として使っている signaling 対 voting しかしマイナーたちは違う考えを持つ 「賛成」と「却下」の投票として使っている

反対をするなら BIP9に入るまでに却下するべき、 コンセンサスの議論しているときに signaling 対 voting 反対をするなら BIP9に入るまでに却下するべき、 コンセンサスの議論しているときに

（細かいことに気を取られて全体を見通せない） penny wise （細かいことに気を取られて全体を見通せない） pound foolish

マイナーにコストは無い Yes/Noを見せるか、後で変えるか 正直な信号を表す マイナーにコストは無い Yes/Noを見せるか、後で変えるか

信号を表すにはコストが必要 その信号が本当であることを証明するため 正直な信号を表す 信号を表すにはコストが必要 その信号が本当であることを証明するため

残りの期間が分かったら 行動に影響をさせることができる タイムアウトは延期になる 残りの期間が分かったら 行動に影響をさせることができる

タイムアウトは延期になる もっと緊急を感じる 残りの時間が短ければ

この緊急性は力を与える Bitcoinをコントロールしたい人には タイムアウトは延期になる この緊急性は力を与える Bitcoinをコントロールしたい人には

この問題を解決する

spork　スポーク sorta probably a fork おそらくフォークかもしれない

単純なスポーク 確率的なブロック・フィルター 上記の条件を満たす後に実行する。 d > hash(hash(block)||“upgrade name”) 上記の条件を満たす後に実行する。

デモ op_cbhv アイデアにラフなコンセンサスがある Bitcoinはリプレーの防護が欲しい Reorgのときに無効化Txを許可する Mempoolのリライトが必要

NOP8  OP_CHECKBLOCKATHEIGHTVERIFY デモ op_cbhv bipのドラフト NOP8  OP_CHECKBLOCKATHEIGHTVERIFY E[activation of rule] = ~6 months h(h(block)||“cbhv”)/(2256-1) < 4e-5

デモ op_cbhv bipのフィードバック＋ラフなコンセンサス 意図的で無いヘッダーのパーシング scriptSig: <header> scriptPubKey: dup sha256 <height> <hash> cbhv dropX3 解決: non-sha256 ハッシュ

bitcoin-core implements spec デモ OP_CBHV リファレンス実装 bitcoin-core implements spec v0.18 + backports to v.014

demo OP_CBHV チェーンのロールアウト 6 months 6 months N 6 months

アップグレードはスポークにのせられたときに 大まかな合意には達している 解析： 投票 アップグレードはスポークにのせられたときに 大まかな合意には達している

マイナーは反対を投票したいときに そのブロックの上に作らなければ良い 解析：　投票 マイナーは反対を投票したいときに そのブロックの上に作らなければ良い

でも反対をするときに 自分のブロックはOrphan Blockになるべき かもしれない 解析：　正直 でも反対をするときに 自分のブロックはOrphan Blockになるべき かもしれない

でも却下されたら難しさは調整される なので、全員のマイナーにずっとコストがある わけではない 解析：　正直 でも却下されたら難しさは調整される なので、全員のマイナーにずっとコストがある わけではない

でも、アップグレードを実行すると インセンティブがある 解析：　正直 でも、アップグレードを実行すると インセンティブがある

確率的なフィルターのアルゴリズムは 独立試行のプロセスである 解析：　タイムアウト 確率的なフィルターのアルゴリズムは 独立試行のプロセスである

つまり、時不変であり 期待実行の時間は一定である 解析：　タイムアウト つまり、時不変であり 期待実行の時間は一定である

E[tactivate] = 6 mo を設定すれば ∀N, E[tactivate | tpassed=N] = 6 months 解析：　タイムアウト E[tactivate] = 6 mo を設定すれば ∀N, E[tactivate | tpassed=N] = 6 months

実行するために皆を待たせるのは マイナーに良いことは無い 解析：　タイムアウト 実行するために皆を待たせるのは マイナーに良いことは無い

スポークの拡張 スポーク・スタートの高さ n-block フェーズの延期 n-block パスを有効にする 早期導入者のルール Orphanに耐える起動

スポーク・スタートの高さ スポークの実行は高さの前には出来ない スポークの互換性に時間を与える

機能が有効になるのはパス後の n ブロック ロックイン後に「調整する」ための時間 n-block フェーズの延期 機能が有効になるのはパス後の n ブロック ロックイン後に「調整する」ための時間

n個のブロック通過フィルタを有効にする 分散を減らし警告を与えるため n-block パスを有効にする n個のブロック通過フィルタを有効にする 分散を減らし警告を与えるため

早期導入者のルール 実行するブロックに互換性が無いと ブロックのリワードを無効にさせる 早めに互換性に対応すること でインセンティブをあげる

自分でOrphanの作成を証明するのは難しくなる 有効なPOWヘッダーの証明で実行する 自分でOrphanの作成を証明するのは難しくなる 拮抗するOrphanの作成を減少する 1 🚀 1😼😼 2😼😼 3 🚀