Develop with pleasure!

福岡でCloudとかBlockchainとか。

Segwitのアップグレードガイド

Bitcoin Segwit

mainnetへのSegwitデプロイを有効にするBitcoin Core 0.13.1がリリースされ、それに合わせてSegwitをサポートしたい人、したくない人向けにアップグレードガイドも公開されてたので見てみる↓
malleabilityの問題や署名の前後でtxidが変わらないのはコントラクトを作る上でも必要な機能なので個人的にはSegwitのリリースは歓迎だけど、Segwitサポートしたくない人向けにも書いてるのが素晴らしい。

bitcoincore.org

Segwitのソフトフォークは、Segwitを採用するかどうか個人の決定にまかせていて、このガイドはSegwitを採用したい人、採用したくない人向けに両者に向けて書かれている。

ソフトフォークのアクティベーションに十分なマイナーの同意が得られたら、Segwitはアクティベーションされ、ユーザはsegregated witnessesなトランザクションを作ることができるようになる。Segwitのソフトフォークは一般的に使われているウォレットにとって前方・後方互換がある形で設計されており、ウォレットの開発者やユーザはそれぞれSegwitを採用するるか採用せずに今まで通りのトランザクションを作るか自由に決められる。

マイナー

このセクションはソロマイナーとマイニングプールのオペレータ向けに書かれている。プールマイナーはSegwitアップグレードするかしないかプールオペレータに問い合わせること。

2016年7月4日にアクティベートされたBIP 68/112/113と同様、BIP-9のソフトフォークのデプロイの仕組みがSegwitにも使われている。アップグレードするかしないか、アップグレードプロセスの重要な段階を理解する必要がある。

  • Started
    Segwitは2016年11月15日以降最初のretarget periodが始まる。これはアクティベートされるか、１年後までにlock-inステータスにならず失敗したと判断されるまで続く。この間、マイナーはブロックヘッダのversion bits １ にフラグをセットすることでSegwitの新しいコンセンサスルールをサポートすることを表明することができる。
  • Locked-in
    2016ブロック内の95%のブロックがSegwitのサポートを表明すると、Segwitのソフトフォークはロックインされ、そこから2016ブロック（約２週間）後にアクティベートされる。
  • Activated
    ロックイン期間が終わると、マイナーは署名が分離されたトランザクションを含むsegwitスタイルのブロックを生成する。

アップグレードしない場合

startedフェーズでは、Segwitを採用したくない場合はBitcoin Core 0.13.1のようなSegwit互換のノードへのアップグレードをせずSegiwtのversion bits 1にフラグをセットするのを避ける。

もしソフトフォークがlocked-inフェーズに入ったら、すぐにアップグレードする必要は無いがノードのアップグレードを推奨する。Segwitのソフトフォークはsegwitスタイルのブロックの生成を強制するものではないので、今まで通りのブロックの生成を継続することができる。しかし、他のマイナー達の支持によりステータスがactivatedになると、あなたは有効と判断しているブロックもsegwitを支持する各ノードはリジェクトし、あなたの作ったブロックは無効であると判断される。

そのためsegwitがlocked-inになった後は、フルノードをBitcoin Core 0.13.1にアップグレードするか、後述するフルノードをアップグレードしない場合に記載されているようにsegwitのフィルタとしてBitcoin 0.13.1もしくはそれ以降のバージョンを使用することを推奨する。

アップグレードする場合

マイナーは2016年11月15日以降、BIP-9のルールに従ってSegwitのサポートを表明することができる。Segwitのサポートを表明するのは以下の作業が必要になる。

  • ブロックに含めるトランザクションの選択とブロックの構成をするのにBitcoin 0.13.1もしくはSegwit互換のフルノードにアップグレードする。
  • マイニングソフトウェアもしくはマイニングプールのソフトウェアをSegwit互換のバージョンにアップグレードする。
  • ブロックを生成する際に、BIP-9に従い、segwitのversion bits 1をセットする。

Segwitがアクティベートされると、Segwitスタイルのブロックのマイニング及びリレーができるようになる。

GetBlockTemplate (GBT)のRPCをサポートするソフトウェアは、BIP-9とBIP-145によるGBTの変更に対応するため必ずアップグレードする必要がある。

Segwitは既にtestnetではアクティベートされているため、testnetを使えば少ないハッシュレートでアップグレードしたインフラでマイニングのテストをすることができる。またBitcoin Core 0.13.1のregtestもデフォルトでSegwitをサポートしている。

フルノードユーザ

フルノードはBitcoinのコンセンサスルールに違反するブロックからユーザを保護する。Segwitのようなソフトフォークを使ったアップグレードでは、新しいルールが追加されても、アップグレードしていないノードはそのルールについて知らない。これは問題ではなく、Segwitのソフトフォークはアップグレードしていないユーザもソフトフォークの前と同じ方法で引き続きBitcoinを利用できるよう設計されている。

しかし、Segwitのソフトフォークで有効になった機能を使いたい人は、充分な数のフルノードユーザがSegwitのルールに違反するブロックやトランザクションを拒否するためノードをアップグレードしたか知りたいだろう。それによってマイナーにSegwitによって更新されたコンセンサスルールに従うインセンティブを提供する。

アップグレードしない場合

マイナーではなくSegwitのアップグレードをしたくない場合、単純に今のフルノードをそのまま使い続ければ良い。Segwitはソフトフォークで実装されているので、アップグレードする必要は無い。またフルノードに接続しているウォレットもアップグレードする必要はなく以前と変わらず利用できる。

しかし、承認数の少ない（１とか２の）トランザクションを受け入れる場合、ソフトフォークがアクティベートされた後は、アップグレードしていないノードが一時的に無効ブロックを受け入れる小さなリスクがあることに注意する必要がある（一部のアップグレードしていないマイナーが作ったブロックが中継されてくる可能性があるため）。その状況はアップグレードしたマイナーがSegwitのコンセンサスルールを継続して強制するため数ブロックで解消するが、無効ブロックで承認されたトランザクションが、その後の有効なブロックで承認されている保証は無い。

この問題を防ぐ一番簡単な方法は、 Bitcoin Core 0.13.1もしくはSegwit互換のフルノードにアップグレードすること。それでもアップグレードしたくない場合は、以下のように、古いBitcoin Coreのフィルタとして新しいBitcoin Coreを使うことができる。

https://bitcoincore.org/assets/images/filtering-by-upgraded-node.svg

この構成では、現在のBitcoin Coreのノード（古いノード）をBitcoin Core 0.13.1以降のノード（新しいノード）にのみ接続するよう設定する。新しいノードの方は通常通りBitcoinのP2Pネットワークに接続する。新しいノードはSegwitのコンセンサスルールの変更の中身を知ってるので、古いノードによって作られた無効ブロックを中継することは無い。

この構成にする際は、Bitcoin Coreのデフォルトを利用している場合、古いノードはSegwitの機能を使ったトランザクションをブロックに入るまで見れないという点に注意する必要がある。

ノードの設定

新しいノードは、普通に起動してブロックチェーンを同期する。現時点でprunedノードは中継ノードとして使えないので、この構成ではprunedノードは使えない。古いノードを特別なノードとして扱うため、以下のパラメータを付けて起動する（もしくは設定ファイルに記述）。

  -whitebind=<addr>
       Bind to given address and whitelist peers connecting to it. Use
       [host]:port notation for IPv6

  -whitelist=<netmask>
       Whitelist peers connecting from the given netmask or IP address. Can be
       specified multiple times. Whitelisted peers cannot be DoS banned
       and their transactions are always relayed, even if they are
       already in the mempool, useful e.g. for a gateway

古いノードは新しいノードのブロックチェーンの同期が終わったら、以下のコマンドラインパラメータを付与して再起動する。

-connect=<新しいノードのIPもしくはDNS名>

これで古いノードは新しいノードにのみ接続され、全てのブロックとトランザクションは新しいノードでフィルタリングされる。

アップグレードする場合

Segwit互換にアップグレードするには、Bitcoin Core 0.13.1のようなSegwit互換のフルノードをダウンロードし、ダウンロードしたファイルが正しいものか（PGPなどで）確認し、旧バージョンのノードを停止し、新しいバージョンのノードを起動する。Segwitがアクティベートされた後にアップグレードした場合、（旧ノードではダウンロードしていないデータがあるため）アクティベーションされた時点からのブロックを再同期する必要があるので注意すること。

Bitcoin CoreのRPCgetblockchaininfoを使うとSegwitのソフトフォークの状況が確認できる。この情報から、最近のブロックのどれくらいがSegwitのコンセンサスルールを適用しようとしているかが分かる。またgetblockchaininfoの結果から、Segwitのソフトフォークがいつlocked-inやactivatedになったのか分かる。

Bitcoin Core 0.13.1のウォレットは、デフォルトでBitcoinの支払いを受け取るため非SegwitのP2PKHのアドレスを生成する。今後のリリースでユーザがSegwitなアドレスで支払いを受け取るか選択できるようになることが期待されている。

もし開発者やエキスパートでテストのためにアドレスを生成したい場合はSegwitの開発ガイドを参照。

ウォレットのユーザ

アップグレードしない場合

Segwitにアップグレードしたくない場合は、Segwitサポートを追加していない任意のウォレットを使えば良い。アップグレードしなくても、Segwitにアップグレードしたユーザとも、アップグレードしてないユーザとも取引をすることはできる。

アップグレードしない場合に唯一違うのは、Segwitに対応したユーザからの支払いを受ける場合、そのトランザクションがブロックに含まれるまであなたのウォレットには表示されない。これはマイナーによって承認されるまで未確認の取引からあなたのウォレットを保護する安全機能である。

アップグレードする場合

Segwitにアップグレードしたい場合は、マイナーがSegwitをアクティベースするのを待ち、Segwitスタイルの支払いや受け取りをサポートするウォレットが必要になる。Bitcoin Coreのウォレットや軽量ウォレット、サードパーティが管理しているウォレット全般に言える。Bitcoin Coreもしくは別のフルノードのユーザは、上記のフルノードのセクション参照。

Segwitをサポートするウォレットにアップグレードしたら、Bitcoinの受け取りようのアドレスとして３で始まるアドレスが生成される（P2SHアドレス）。

一般的なウォレットはほとんどP2SHアドレスへの支払いができるため、他のユーザがSegwitにアップグレードしているかどうかに関係なく、P2SHを使って支払いを受け取ることができる。Segwitにアップグレード後にBitcoinの支払いをする場合、元々の１から始まるBitcoinアドレス（P2PKHアドレス）に支払いをすることができる。

Segwit対応のウォレットを使ってBitcoinを送ると、次のような点が分かる。

  • アップグレード前に受信したBitcoinを使う時に作られるトランザクションはSegwitのアップグレード前に作られるトランザクションとなんら変わりはない。
  • アップグレード後に受信したBitcoinをSegwitのアップグレードしていないユーザに送る場合、そのトランザクションはブロックに入れられるまで相手には表示されない。これはトランザクションがブロックに含まれるまで、このトランザクションを完全に理解できないウォレットにそのトランザクションを示すことを回避する安全機能である。トランザクションが承認されると受領したBitcoinが見れるようになりいつもどおりに使うことができる。
  • アップグレード後に新しいP2SHアドレスで受信したBitcoinを使う際、非SegwitなUTXOを使った時より若干手数料が安いことに気付くだろう。これは、署名が含まれているトランザクションの一部のデータにBitcoinのフルノードが迅速にアクセスする必要が無いため、Segwitによりマイナーは非witnessなデータの４倍のwitnessデータを保存できるようになっている。そのためブロック作成コストとの調整で手数料が安くなっている。

Bitcoinのソフトウェア開発者

全てのBitcoinのソフトウェアは以前と同様に動作するべきで、Segwitの新しい機能のアドバンテージを利用したい場合はソフトウェアをアップグレードする必要がある。

Segwitの開発者のためのドキュメントが↓

Segwitのアドレスフォーマットを定義したBIP-142のステータスはdeferredで、標準ではないので注意すること。代わりにbitcoin-devのMLで現在のBase58エンコードしたアドレスより使いやすい新しいBitcoinのアドレスフォーマットについて議論されている。

BIP141、143、144、および145のほとんど実装はBitcoin CoreのPR#8149で確認できる。また、BIP-147の実装はPR#8636。

Segwit対応のテストは、testnetがSegwitのサポートをしており、ここ数ヶ月の間で多数のSegwitのブロックができている。またSegwitのブロックの最大サイズ（4MB）に近いサイズのブロックも作られている。Bitcoin Core 0.13.0と0.13.1のregtestもデフォルトでSegwitをサポートしている。

参考

参考までに関連するBIPを以前意訳したもの↓

techmedia-think.hatenablog.com

techmedia-think.hatenablog.com

techmedia-think.hatenablog.com

techmedia-think.hatenablog.com

所感

  • Segwit対応したBitcoin Coreのウォレットでは、受信用のアドレスはP2SHになるみたい（P2WPKHをネストしたP2SH）。
  • Segwitのアドレスを定義したBIP-142は結局実装に含まれてなく、支払いの受け取りアドレスもP2PKHアドレスを引き続き生成してるので、Segwitなアドレスが定義されるまではP2WPKHやP2WSHとかのトランザクションは少なく、基本はP2SHでネストしたアドレスが主流か？
  • まだブロックに含まれていないトランザクションも、そのトランザクションデータを受信すれば0 confirmationのUTXOとして認識できるけど、Segwit互換のノードにアップグレードしていない場合は、Segwitのトランザクションはブロックに入れられるまで認識できなくなると。
    0 confirmationで決済してる事業者とかは事前にSegwitへのアップグレードが必須。
  • Segwitのリリースだけじゃなく、BIP-147も一緒にデプロイされると。