ビットコインコードレポート – 2016年12月10日

Bitcoin Unlimited コードの変更

—-gandrewstone は、「追加のCCriticalSection破壊依存関係の解決」に関する 6 つの変更ファイルを送信しました。合計で 81 の追加と 59 の削除が含まれています。これらの変更により、CCriticalSection で発生した問題が解決されます。

--nomnombtc 「 build-unix.mdのタイプミスを修正」に 1 件の変更をコミットしました (4 件の追加と 4 件の削除)。これらの変更により、例の「Core」という単語が「Unlimited」に置き換えられ、いくつかの小さなタイプミスが修正され、configure プレフィックスに環境変数「 $pwd 」が追加されます。

---ftrader は、「固有の拡張テストを実行するためにrpc-tests.pyに固有の拡張オプションを追加する」に関する変更ファイルを 1 つ送信しました。合計で 6 つの追加と 3 つの削除が行われました。これらの変更により、「 runtests 」が入力されたときに、「rpc-tets.py」が拡張テストのみを実行するようになります。

Bitcoin Classic コードの変更

—zander 「エラー メッセージの改善」に関する変更ファイルを 1 つ送信しました。これには 2 つの追加と 2 つの削除が含まれます。これらの変更は、エラーが発生したときに古いエラー メッセージを、より簡潔で正確な出力に置き換えることにより、「 fTestNet 」および「 fRegTest 」に影響します。

—-zander は、「市場ベースの均衡ブロックサイズの実装」に関する 24 の変更ファイルを送信し、89 の追加と 945 の削除を行いました。これらの変更により、Core にコミットされた 2MB のブロックサイズである BIP109 が削除され、「市場均衡に基づく動的なブロックサイズ設定」に置き換えられます。ザンダー氏はこれを次のように説明しました。「コンセンサス ルールから最大ブロック サイズを削除しました。他のノードから受け入れる最大ブロック サイズを定義するコマンド ライン パラメータを導入しました。」これにより、Bitcoin Classic は Bitcoin Unlimited と互換性を保ちながら、マイナーが「-blockmaxsize」を使用して作成するブロック サイズを設定し、「-blocksizeacceptlimit」を使用して受け入れるブロック サイズを制限することが可能になります。

Bitcoin XT コードの変更

–dgenr8 1 つのコミット「 dagurval:cachebump 」を「 bitcoinxt:master 」にマージします。マージ中に 2 つのファイルが変更され、合計 13 個が追加され、5 個が削除されました。変更は主にコードの最適化ですが、「 nMaxBlockDBAndTxIndexCache 」に関するセクションが書き直されました。

Bitcoin Coreコードの変更

– sipa 2つのコミット「 gmaxwell:node_is_this_i_dont_even 」を「 bitcoin:master 」にマージします。マージ中に 3 つのファイルが変更され、合計 3 つの追加と 22 の削除が行われました。これらの変更により、元のビットコイン コードに存在していた「 Pub Sub Mechanism 」の一部が削除されました。この「Pub Sub メカニズム」は Merge #1036 で非推奨になりました。 gmaxwell から削除された後続のコードは、無視できないこのシステムをサポートするために使用されました。

- iaanwj は、「 torcontrol : RSA1024 秘密キーを明示的に要求する」に関する 1 つの変更ファイルをコミットし、1 つを追加、1 つを削除しました。この変更により、新しく生成されるすべての秘密鍵が RSA1024 形式になります。現在のビットコイン P2P プロトコルは ed25519 キーをサポートしていないため、RSA1024 キーを明示的に要求することが重要です。

- iaanwj は、「doc: Linux サブシステムを使用した Windows ビルド手順の改善」に 46 の追加と 20 の変更を加えた 1 つの変更ファイルを送信しました。これらの変更は、Windows Subsystem for Linux のビルド手順をよりユーザーフレンドリーにすることを目的としています。これは主に、64 ビット命令を最初に配置し、二重スペースを削除し、ビルド ユーザーへの提案やヒントを提供することで行われます。

- paveljanik は、「セキュリティ問題の責任ある報告について」に関する 1 つの変更ファイルをコミットし、2 つの追加と 0 つの削除を行いました。 .github / ISSUE_TEMPLATE.mdへのこれらの追加は、ユーザーが Bitcoin Core に問題を最も適切に送信できるように、明確な情報をユーザーに提供することを目的としています。

ビットコインエコシステムからのニュース

Bitcoin Classic はサブレディット r/btc で「Bitcoin Classic が復活しました!」と発表しました。 Bitcoin Classic チームは過去 1 年間、クライアントの更新と改善に懸命に取り組んできました。最新のプロジェクトの 1 つに、Bitcoin のトランザクション形式の更新が含まれています。この新しいクラシック形式は、トランザクション バージョン 4 と呼ばれ、一般的には Flex Transactions として知られています。

頭字語 Flex Transaction を使用することは、このトランザクション形式を考えるいくつかの方法の 1 つです。 Deadalnix は、トランザクション形式を簡素化する方法として flex トランザクションを提供してくれました。

「現在のトランザクション形式には根本的な問題があります。各トランザクションは署名を検証するためにハッシュ化されますが、署名はトランザクション データ構造内にあります。そのため、トランザクション内の署名、ハッシュ、シンボルなどを削除するには非常に複雑なプロセスがあります。不必要な複雑さに加えて、これは 2 つの問題につながります。最初の問題は、署名ごとにトランザクション全体を再ハッシュする必要があることです。これにより、「2 次ハッシュ問題」と呼ばれるものが発生します。簡単に言えば、大規模なトランザクションの検証には非常にコストがかかります。2 番目の問題は、トランザクションの可鍛性です。署名を変更することで、トランザクション ID を変更でき、コードがトランザクション ID を信頼できなくなります。これにより、SPV セキュリティに多くの問題が発生します。これは、ライトニング ネットワークが直面する必要がある技術的な問題でもあります。両方の問題を解決するには、署名を削除して、トランザクション ID の計算に使用されないようにし、署名の検証に使用されるハッシュ データの一部にならないようにします。 Segregated Witness と Flexible Transactions の両方でこれを行うことができますが、Flex Transaction はハードフォークとして登場し、Segregated Witness はソフトフォークとして登場します。ハードフォークを介してトランザクションを調整すると、これらの問題が発生しない新しいトランザクション形式が作成されます。ただし、ソフトフォークであるため、古いノードにトランザクションを有効とみなさせる必要があります。つまり、Segregated Witness の仕組みは、分離されたトランザクションが古い形式であり、誰でも古いトランザクションを古い形式で古いノードに送信できるというものです。そのため、未使用のトランザクション出力は分離され、未使用のトランザクション出力は分離されず、それに伴うすべての問題が発生します。一方、Flex Transaction は新しいトランザクション形式を導入します。古いノードはこの形式を理解できないため、Flex Transaction を有効にすると、すべてのノードを更新する必要があります。一方、Flex Transaction は互換性のある未使用のトランザクション出力を使用するため、古いトランザクション形式は時間の経過とともに徐々に廃止されます。これらの問題は完全に解決されるだろう。」

Bitcoin Unlimited の主任開発者 Andrew Stone 氏は、今週、Bitcoin Unlimited の最新のコード変更とソフトウェアの計画についていくつかの質問に答えてくれました。質問は次のとおりです:

Q: 最近のコミットは、GitHub の破壊依存関係の処理に関するものでした。この変更の目的を簡単に説明していただけますか?

A: Bitcoin Unlimited を非常に安定したものにするためのプロジェクトが進行中です。すべての Satoshi クライアントには、構築と解体に関するバグがあります。 1 つ目は、一部のグローバル変数は相互に依存していますが、それらの分解順序は保証されていないことです。グローバル変数を単一のフォルダーに移動することで、構造化順序を効果的に制御できます。もう 1 つの問題は、クライアントがデッドロック検出を長時間実行できないことです。CCriticalSection オブジェクトは分解されると検出から削除されるため、誤検出が発生します。これらの問題はすべて Bitcoin Unlimited で修正されました。

Q: 現在取り組んでいる BU プロジェクトについて詳しく教えていただけますか?一般の人々が知っておくべきと思われる、興味深い進展はありますか?

A: 新しいバージョンの開発に全力で取り組んでいます!新バージョンの最後の機能は、非常に高価なトランザクションを防ぐための「エマージェントコンセンサス」タイプのパラメータの追加です。 （翻訳者注：この段落の意味は、私が別の BU 開発者ブログで見たものと合わせて考えると、Bitcoin Unlimited が BUIP041 を導入して、少数のコンピューティング フォースが大規模なブロック攻撃を仕掛けるのを防ぐということであるはずです。）

Bitcoin Unlimited チームは、新しいリリースに関する詳細情報を近日中に公開する予定です。