今週のニュースレターでは、取引可能なecashシェアでプールマイナーに報酬を与えることについての継続的な議論と、 DLCのオフチェーン解決を可能にする新しい提案を掲載しています。また、 新しいリリースとリリース候補の発表や、人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更など、 恒例のセクションも含まれています。

ニュース

• ● 取引可能なecachシェアでプールマイナーに報酬を与えることについての継続的な議論: プールマイナーが提出したシェア毎にecashを支払うことについての Delving Bitcoinスレッドでの以前の要約以降、議論が続いています。 以前、Matt Coralloは、通常のecashのミントを使用して（またはLNを介して）マイナーに支払うだけで済むのに、 なぜプールが取引可能なecashシェアを処理するために追加のコードと計算を実装するのかと質問しました。 David Caseriaは、TIDESのような一部のPPLNS（Pay Per Last N Shares）方式では、 マイナーはプールが複数のブロックを見つけるのを待つ必要があり、 小規模なプールの場合は数日または数週間かかる可能性があると回答しました。 それを待つ代わりに、ecashのシェアを持つマイナーは、それをオープンマーケットですぐに販売できます（ プールや第三者に自分のIDに関する情報を開示することなく、マイニング時に使用した一時的なIDさえも開示する必要がありません）。

  Caseriaはまた、既存のマイニングプールは、マイナーがシェアを作成した際に、 全ブロック報酬（報酬＋トランザクション手数料）に比例した報酬を受け取る FPPS（Full Paid Per Share）方式をサポートするのは財政的に困難であると指摘しています。 彼は詳しく説明しませんでしたが、問題は手数料のばらつきによりプールが多額の準備金を保有せざるを得ないことだと理解しています。 たとえば、プールのマイナーがハッシュレートの1%を制御している場合、 手数料が約1,000 BTCでブロック報酬が3 BTCのテンプレートでシェアを作成する場合、 プールは約10 BTCを支払う義務があります。しかし、プールがそのブロックをマイニングせず、 ブロックをマイニングした際の手数料がブロック報酬の何分の一かに下がっていた場合、 プールが全マイナーに分配できるのは合計3 BTCで、準備金からの支払いを余儀なくされるかもしれません。 これが何度も発生すると、プールの準備金が枯渇し、廃業することになります。 プールは、実際の手数料にプロキシを使用するなど、さまざまな方法でこれに対処しています。

  開発者のvnprcは、PPLNS支払い方式で受け取ったecashシェアに焦点を当てた、 彼が構築中のソリューションについて説明しました。 彼は、これが新しいプールの立ち上げに特に役立つ可能性があると考えています。 現在、プールに最初に参加するマイナーは、ソロマイニングと同じ高い変動に悩まされるため、 通常、プールを開始できるのは既存の大規模なマイナーか、大規模なハッシュレートを借りたい意思のある人だけです。 ただ、PPLNS ecashシェアを使用すると、プールをより大きなプールのクライアントとして立ち上げることができるため、 vnprcは新しいプールに最初に参加するマイナーでも、ソロマイニングよりも変動が少なくなると考えています。 中間プールはその後、獲得したecashシェアを販売して、マイナーに支払うために選択した支払い方式の資金を調達できます。 中間プールがかなりの量のハッシュレートを獲得すると、マイナーに適した代替ブロックテンプレートの作成について、 より大きなプールと交渉するための影響力も得られます。

• ● オフチェーンDLC: 開発者のconduitionは、両参加者が署名したファンディングトランザクションの オフチェーン支払いで複数のDLCを作成できるコントラクトプロトコルについて、 DLCメーリングリストに投稿しました。 （必要なオラクルの署名が入手されたなどして）オフチェーンDLCが決済されると、 両参加者は新しいオフチェーン支払いに署名し、コントラクトの解決に従って資金を再割り当てできます。 その後、3つめの代替支払いで資金を新しいDLCに割り当てることができます。

  Kulpreet SinghとPhilipp Hoenischによる返信は、 同じ資金プールをオフチェーンDLCとLNの両方に使用できるアプローチ（ニュースレター#174および #260参照）を含む、この基本的なアイディアの以前の研究と開発にリンクしています。 conduitionからの返信では、彼の提案と以前の提案の主な違いが説明されていました。

リリースとリリース候補

人気のBitcoinインフラストラクチャプロジェクトの新しいリリースとリリース候補。 新しいリリースにアップグレードしたり、リリース候補のテストを支援することを検討してください。

• ● LDK v0.1は、LN対応ウォレットやアプリケーションを構築するためのこのライブラリのマイルストーンリリースです。 新機能には、「LSPSチャネル開設ネゴシエーションプロトコルの両サイドのサポート、… BIP353の人が読める名前解決のサポート、単一チャネルの強制閉鎖で複数のHTLCを解決する際のオンチェーン手数料コストの削減」が 含まれています。

注目すべきコードとドキュメントの変更

最近のBitcoin Core、Core Lightning、Eclair、LDK、 LND、libsecp256k1、Hardware Wallet Interface (HWI)、Rust Bitcoin、BTCPay Server、BDK、Bitcoin Improvement Proposals（BIP）、Lightning BOLTs、 Bitcoin InquisitionおよびBINANAsの注目すべき変更点。

• ● Eclair #2936では、スプライシングの更新を伝播できるように（ニュースレター#214および Eclair開発者による動機の説明参照）、ファンディングアウトプットが使用された後、 チャネルがクローズされたとマークするまでに12ブロックの遅延が導入されました。 使用されたチャネルは一時的に新しいspentChannelsマップで追跡され、 12ブロック後に削除されるか、スプライシングされたチャネルとして更新されます。 スプライシングが発生すると、新しいチャネルを作成する代わりに、親チャネルのショートチャネル識別子（SCID）、 キャパシティおよび残高の境界が更新されます。

• ● Rust Bitcoin #3792では、BIP324のv2 P2Pトランスポートメッセージ （ニュースレター#306参照）をエンコード/デコードする機能を追加します。 これは、元のNetworkMessage列挙型をラップして、v2のエンコード/デコードを提供する V2NetworkMessage構造体を追加することで実現されています。

• ● BDK #1789は、デフォルトのトランザクションバージョンを1から2に更新し、 ウォレットのプライバシーを向上させます。これ以前は、バージョン1を使用しているのはネットワークの15%のみであったため、 BDKウォレットはより識別可能でした。さらに、バージョン2は、Taprootトランザクション用に BIP326のnSequenceベースのアンチ・フィー・スナイピングメカニズムの将来の実装に必要です。

• ● BIPs #1687は、PSBTを使用したサイレントペイメントの送信を定義するBIP375をマージしました。複数の独立した署名者がいる場合、 すべての署名者が自分の秘密鍵を明かすことなく、自分の署名が資金を誤支払いしないことを共同署名者に証明できる DLEQプルーフが必要です（ニュースレター #335およびRecap #327参照）。

• ● BIPs #1396は、BIP78のPayjoin仕様を更新し、 BIP174のPSBT仕様と一致させ、これまでの競合を解決します。 BIP78では、送信者がデータを必要としている場合でも、受信者はインプットが完成するとUTXOデータを削除していました。 今回の更新により、UTXOデータは保持されるようになりました。

もっと知りたいですか？

このニュースレターで言及されたトピックについてもっと議論したい方は、 （ニュース レターが公開された翌日の）木曜日の15:30 UTCから Riverside.fmで毎週開催されているBitcoin Optech Recapにご参加ください。この議 論は録画もされ、ポッドキャストページからご覧いただけます。