/ home / newsletters /
Bitcoin Optech Newsletter #398
今週のニュースレターでは、Bitcoin Stack Exchangeから厳選された質問と回答や、 新しいリリースおよびリリース候補の発表、人気のBitcoin基盤ソフトウェアの注目すべき更新など 恒例のセクションが掲載されています。
ニュース
今週は、どの情報源からも重要なニュースは見つかりませんでした。
Bitcoin Stack Exchangeから選ばれたQ&A
Bitcoin Stack ExchangeはOptech Contributor達が疑問に対して答えを探しに(もしくは他のユーザーの質問に答える時間がある場合に)アクセスする、 数少ない情報ソースです。この月刊セクションでは、前回アップデート以降にされた、最も票を集めた質問・回答を紹介しています。
-
● 「Bitcoinでは暗号化を使用していない」とはどういう意味ですか? Pieter Wuilleは、認可されていない第三者からデータを秘匿するための暗号化(BitcoinのECDSAはこの目的には使用できない)と、 Bitcoinが検証および認証に使用するデジタル署名とを区別しています。
-
● Bitcoin Scriptはいつ、なぜコミット-開示構造に移行したのですか? ユーザーbca-0353f40eは、ユーザーが公開鍵に直接支払うBitcoinの初期のアプローチから、 P2PKHやP2SH、segwit、taprootへと進化してきた経緯を説明しています。 これらのアプローチでは、使用条件がアウトプットにコミットされ、使用時にのみ開示されます。
-
● P2TR-MS (TaprootのM-of-Nマルチシグ) は公開鍵を漏洩しますか? Murchは、単一リーフのTaprootのスクリプトパスマルチシグでは、 OP_CHECKSIGとOP_CHECKSIGADDの両方が署名に対応する公開鍵の存在を要求するため、 使用時にすべての対象公開鍵が公開されることを確認しています。
-
● OP_CHECKSIGFROMSTACKは、意図的にUTXO間で署名の再利用を許可しているのですか? ユーザーbca-0353f40eは、OP_CHECKSIGFROMSTACK(BIP348)が 意図的に署名を特定のインプットにバインドしないことを説明しています。これにより、 CSFSを他のコベナンツopcodeと組み合わせて再バインド可能な署名を実現でき、 これがLN-Symmetryの基盤となるメカニズムです。
リリースとリリース候補
人気のBitcoinインフラストラクチャプロジェクトの新しいリリースとリリース候補。 新しいリリースにアップグレードしたり、リリース候補のテストを支援することを検討してください。
-
● Bitcoin Core 28.4は、主要なフルノード実装の以前のメジャーリリースシリーズのメンテナンスリリースです。 主に、ウォレットの移行に関する修正と、信頼性の低いDNSシードの削除が含まれています。 詳細は、リリースノートをご覧ください。
-
● Core Lightning 26.04rc1は、この人気のLNノードの次期メジャーバージョンのリリース候補で、 多数のスプライシング関連の更新とバグ修正が含まれています。
注目すべきコードとドキュメントの変更
最近のBitcoin Core、Core Lightning、Eclair、LDK、 LND、libsecp256k1、Hardware Wallet Interface (HWI)、Rust Bitcoin、BTCPay Server、BDK、Bitcoin Improvement Proposals(BIP)、Lightning BOLTs、Lightning BLIPs、 Bitcoin InquisitionおよびBINANAsの注目すべき変更点。
-
● Bitcoin Core #33259は、assumeUTXOスナップショットを使用するノード向けに、
getblockchaininfoRPCのレスポンスにbackgroundvalidationフィールドを追加しました。 この新しいフィールドは、スナップショットの高さ、バックグラウンド検証の現在のブロック高とハッシュ、 中央値時間、chainworkおよび検証の進捗状況を報告します。これまでは、getblockchaininfoのレスポンスは、 検証とIBDが完了したことを単に示すだけで、バックグラウンド検証に関する情報はありませんでした。 -
● Bitcoin Core #33414は、接続されたTorデーモンがサポートしている場合に、 自動作成されたオニオンサービスに対してTorのProof of Work防御を有効にします。 Torデーモンがアクセス可能なコントロールポートを持ち、Bitcoin Coreの
listenonion設定がオン(デフォルト)の場合、 自動的にHidden Serviceが作成されます。これは手動で作成されたオニオンサービスには適用されませんが、 ユーザーにはProof of Work防御を有効にするためにHiddenServicePoWDefensesEnabled 1を追加することが推奨されています。 -
● Bitcoin Core #34846は、タイムロックフィールドにアクセスするための関数
btck_transaction_get_locktimeおよびbtck_transaction_input_get_sequenceをlibbitcoinkernelC API(ニュースレター #380参照)に追加しました。 これはトランザクションのnLockTimeおよびインプットのnSequenceにアクセスするためのものです。 これにより、トランザクションを手動でデシリアライズすることなく、 BIP54(コンセンサスクリーンナップ)のルール(コインベースのnLockTime制約など)を検証できるようになります(sigops制限など他のBIP54ルールは、 引き続き個別の処理が必要です)。 -
● Core Lightning #8450は、CLNのスプライススクリプトエンジンを拡張し、 クロスチャネルスプライス、(3つ以上の)マルチチャネルスプライスおよび動的な手数料計算を処理できるようにしました。 これが解決する主な問題は、手数料推定における循環依存です。ウォレットインプットを追加するとトランザクションのウェイトが増加し、 それに伴い必要な手数料も増加し、さらに追加のインプットが必要になる場合があります。 このインフラは、新しい
spliceinおよびspliceoutRPCの基盤となっています。 -
● Core Lightning #8856および#8857は、 内部ウォレットからチャネルに資金を追加するための
spliceinRPCコマンドと、 チャネルから内部ウォレットやBitcoinアドレスまたは別のチャネル(事実上クロススプライス)に資金を移動するためのspliceoutRPCコマンドを追加しました。この新しいコマンドにより、オペレーターが実験的なdev-spliceRPCを使ってスプライシングトランザクションを手動で構築する必要がなくなります。 -
● Eclair #3247は、ピア毎の転送収益と支払いボリュームを時系列で追跡するオプションのピアスコアリングシステムを追加しました。 有効にすると、定期的にピアの収益性をランク付けし、オプションで収益上位のピアへのチャネルの自動ファンディング、 流動性を回収するための非生産的なチャネルの自動閉鎖およびボリュームに基づくリレー手数料の自動調整を、 すべて設定可能な範囲内で行うことができます。オペレーターは、自動化を選択する前に、 まず可視化のみから始めることができます。
-
● LDK #4472は、チャネルのファンディングおよびスプライシング中に、 相手方のコミットメント署名が永続化される前に
tx_signaturesが送信される可能性がある資金喪失シナリオを修正しました。 トランザクションが承認された後にノードがクラッシュした場合、チャネル状態を強制する能力が失われる可能性がありました。 この修正は、対応するモニターの更新が完了するまで、tx_signaturesの送信を遅延させます。 -
● LND #10602は、実験的な
switchrpcサブシステム(ニュースレター #386参照)にDeleteAttemptsRPCを追加し、外部コントローラーがLNDの試行ストアから完了(保留中でない、成功または失敗)した HTLC試行レコードを明示的に削除できるようにしました。 -
● LND #10481は、LNDの統合テストフレームワークに
bitcoindマイナーバックエンドを追加しました。 これまでは、lntestは、bitcoindをチェーンのバックエンドとして使用する場合でも、btcdベースのマイナーを前提としていました。この変更により、v3トランザクションリレーや パッケージリレーを含む、 Bitcoin Coreのmempoolおよびマイニングポリシーに依存する動作をテストできるようになります。 -
● BOLTs #1160は、スプライシングプロトコルをライトニングの仕様にマージしました。 BOLTs #863のドラフトを、書き換えの動機となったエッジケースの更新されたフローとテストベクトルで置き換えています( そのドラフトが活発に開発されていた頃の議論については、ニュースレター #246参照)。 スプライシングにより、ピアはチャネルを閉じることなく資金を追加または削除できます。 ネゴシエーションは静止状態(BOLTs #869、ニュースレター #309参照)から開始されます。 マージされたBOLT2のテキストは、スプライストランザクションの対話的な構築、 スプライスが未承認の間のチャネル運用の継続、保留中のスプライスのRBF、 再接続時の動作、十分な深さの後の
splice_lockedおよび更新されたチャネルアナウンスをカバーしています。
もっと知りたいですか?
このニュースレターで言及されたトピックについてもっと議論したい方は、 16:30 UTCに Riverside.fmで毎週配信されているBitcoin Optech Recapにご参加ください。 この議論は録画もされ、ポッドキャストページからご覧いただけます。