these are protocols used for changing the bitcoin network protocols

Presentation on theme: "these are protocols used for changing the bitcoin network protocols"— Presentation transcript:

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

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

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

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

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

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

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

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

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

10 Bitcoinのソフト・フォーク

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

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

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

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

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

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

17 小さな誤解 大きな論争

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

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

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

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

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

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

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

25

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

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

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

29 この問題を解決する

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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