ASICBoost

Timo Hanke は 2016 年の論文で ASICBoost を説明し、Sergio Demian Lerner との協力を記しています。ASIC の外での作業準備とチップ内の計算構成を組み合わせます。SHA-256 も、最終的な二重ヘッダーハッシュが採掘目標を満たす要件も変えず、反復演算の一部を節約します。 [Timo Hanke — AsicBoost, 2016]

Bitcoin ヘッダーは 80 バイトです。最初の SHA-256 では 64 バイトと、padding を追加した残り 16 バイトに分かれます。Merkle root は両方にまたがり、最後の 4 バイトは時刻、bits、nonce とともに後半にあります。変更するデータの正確な位置が重要です。 [Timo Hanke — AsicBoost, 2016]

Hanke の colliding work items は同じ Message と、前半から得る異なる midstate を持ちます。選んだ nonce に対し、最初の SHA-256 の後半の message schedule をこれらの状態間で再利用できます。SHA-256 全体の衝突でも、ヘッダー前半が同一という意味でもありません。前半は異なります。 [Timo Hanke — AsicBoost, 2016]

Lerner は nVersion を変更する overt と、最後の 4 バイトが同じで前半が異なる Merkle root を探す covert を区別します。Covert はトランザクションや順序を変更できますが、コミットメントと依存関係の有効性を保つ必要があります。nVersion の変化だけでは特定の節約量や運営者の身元は証明できません。 [Sergio Demian Lerner — Overt and covert AsicBoost, 2017]

BIP310 は mining.configure と version-rolling.mask を使い、応答はサーバーと採掘者の対応範囲の共通部分です。提出は version_bits & ~last_mask == 0 を満たす必要があります。mining.set_version_mask は次のジョブからではなく直ちに有効です。Version rolling 対応は任意のビット変更や新しいマスクの無視を許しません。 [BIP310 — Stratum protocol extensions]

確認日時点で BIP320 は Draft で、汎用 nVersion ビット 16 個を記述しています。BIP323 も Draft で、24 ビットへの置換を提案しています。文書と、個々の接続で実際に使うマスクやソフトウェアを区別してください。BIP 番号だけで全機器の対応や任意の合意規則変更は証明できません。 [BIP320 — General-purpose nVersion bits] [BIP323 — 24 general-purpose nVersion bits]

Hanke のモデルは x × (n − 1) / n で、x は共有する展開処理の割合、n は適切なジョブ数です。x = 25%、n = 4 なら 18.75% です。この仮定での計算作業モデルであり、すべての採掘機で同率のワット数や価格の低下、ハッシュレート向上が自動的に得られる意味ではありません。 [Timo Hanke — AsicBoost, 2016]

個々の機器についてチップとファームウェアの対応、交渉したマスク、受理された作業、比較可能な条件での消費電力を記録します。機器全体の J/TH は機能名や理論的割合だけでは代替できません。ASICBoost はオーバークロックの同義語ではなく、ブロック発見や利益を保証しません。 [Timo Hanke — AsicBoost, 2016] [BIP310 — Stratum protocol extensions]