今週のニュースレターでは、Bitcoinスクリプト用のLisp方言に関する最近の議論を掲載しています。 また、Bitcoin Stack Exchangeで人気の質問とその回答や、新しいリリースとリリース候補の発表、 人気のあるBitcoinインフラストラクチャプロジェクトの注目すべき変更など恒例のセクションも含まれています。

ニュース

  • Bitcoinスクリプト用のLisp方言: Anthony Townsは、 ソフトフォークでBitcoinに追加可能なBitcoin用のLisp方言を作成する研究の続きについて、 いくつか投稿しました。

    • bll, symbll, bllsh: Townsは、Chia Lisp開発者のArt Yerkesからの、 (プログラマーが通常書く)高レベルコードと(実際に実行されるもので、 通常はコンパイラによって高レベルコードから作成される)低レベルコード間の適切なマッピングを確保するためのアドバイスについて、 長い間考えていたと述べています。彼は、 「(miniscriptがスクリプトに対して行うように)高レベル言語を低レベル言語の使いやすいバリエーションとして扱う」 というminiscriptのようなアプローチを取ることにしました。 その結果、2つの言語と1つのツールができました。

      • Basic Bitcoin Lisp言語 (bll) は、ソフトフォークでBitcoinに追加できる低レベルの言語です。 Townsによると、前回の更新時点(ニュースレター #294参照)で、 bllはBTC Lispに似ています。

      • シンボリックbll (symbll) は、bllに変換される高レベル言語です。 関数型プログラミングに慣れている人にとっては、比較的簡単なはずです。

      • Bllシェル (bllsh) は、bllとsymbllでスクリプトをテストし、 symbllからbllにコンパイルし、デバッグ機能を使用してコードを実行できるREPLです。

    • symbllとGSRにおける量子安全な署名の実装: Townsは、既存のopcodeとRusty RussellのGSR(Great Script Restoration提案で定義されたopcodeを使用して Winternitz One Time Signatures (WOTS+)を実装することに関するJonas NickのTwitter投稿リンクしています。 Townsは、次にbllshでsymbllを使用してWOTSを実装することを比較しました。 これにより、オンチェーンに配置する必要があるデータ量が少なくとも83%、場合によっては95%以上削減されます。 これにより、P2WPKHアウトプットの30倍のコストで量子安全な署名を使用することができます。

    • 柔軟なコインの用途指定: Townsは、1つのUTXOを特定の金額と使用条件に分割できるsymbll(およびおそらくSimplicity)と互換性のある 汎用構造について説明しています。使用条件が満たされると、 関連付けられた金額を使用することができ、UTXOの残りの金額は残りの条件と一緒に新しいUTXOに戻されます。 UTXOのすべて使用できるようにする別の条件が満たされる場合もあります。たとえば、 これによりすべての参加者が条件の一部を更新することに同意できるようになります。これはTownsが以前提案した OP_TAP_LEAF_UPDATE_VERIFY(TLUV、ニュースレター #166参照)に似た 柔軟なタイプのコベナンツの仕組みですが、Townsは以前、 コベナンツは「正確でも有用な用語でもない」と考えていると書いています

      LN-Symmetryベースのチャネルを含む)LNチャネルのセキュリティとユーザビリティの向上や、 BIP345版のVaultの代替、 TLUVで使用することが検討されているのと同様のペイメントプールの設計であるものの x-only公開鍵でその提案が抱えていた問題を回避するものなど、 これらの 柔軟なコインの用途指定 をどのように使用できるかについて、いくつかの例が示されています。

Bitcoin Stack Exchangeから選ばれたQ&A

Bitcoin Stack ExchangeはOptech Contributor達が疑問に対して答えを探しに(もしくは他のユーザーの質問に答える時間がある場合に)アクセスする、 数少ない情報ソースです。この月刊セクションでは、前回アップデート以降にされた、最も票を集めた質問・回答を紹介しています。

リリースとリリース候補

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

  • Core Lightning 24.11rc2は、この人気のLN実装の次期メジャーバージョンのリリース候補です。

  • BDK 0.30.0は、ウォレットや他のBitcoin対応アプリケーションを構築するための このライブラリのリリースです。いくつかのマイナーなバグ修正が含まれており、 ライブラリのバージョン1.0へのアップグレードが予定されています。

  • LND 0.18.4-beta.rc1は、この人気のLN実装のマイナーバージョンのリリース候補です。

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

最近のBitcoin CoreCore LightningEclairLDKLNDlibsecp256k1Hardware Wallet Interface (HWI)Rust BitcoinBTCPay ServerBDKBitcoin Improvement Proposals(BIP)Lightning BOLTsBitcoin InquisitionおよびBINANAsの注目すべき変更点。

  • Bitcoin Core #31122は、mempoolのchangesetインターフェースを実装し、 ノードが提案されたお釣りのセットがmempoolの状態に与える影響を計算できるようにします。 たとえば、トランザクションやパッケージが受け入れられた際に、 祖先/子孫/TRUC(および将来のクラスター)の制限に違反しているかどうかを確認したり、 RBFによる手数料の引き上げによってmempoolの状態が改善されるかどうかを判断したりします。 このPRは、クラスターmempoolプロジェクトの一部です。

  • Core Lightning #7852は、descriptionフィールドを再導入することで、 pyln-clientプラグイン(Pythonのクライアントライブラリ)の24.08未満のバージョンとの下位互換性を復元します。

  • Core Lightning #7740は、askreneニュースレター #316参照)プラグインの 最小コストフロー(MCF)ソルバーを改善し、MCF解法の複雑さを抽象化するAPIを提供することで、 新しく追加されたグラフベースのフロー計算アルゴリズムの統合を容易にしました。 このソルバーは、renepayニュースレター #263参照)と同じ チャネルコスト関数のリニアライゼーションを採用し、経路探索の信頼性を向上させています。 また、msatsを超えるカスタマイズ可能な単位のサポートを導入し、大きめな支払いのためのスケーラビリティを向上させています。 このPRでは、フロー計算の効率を向上させるために、simple_feasibleflowget_augmenting_flowaugment_flownode_balanceメソッドを追加しています。

  • Core Lightning #7719は、Eclairとのスプライシングの相互運用を実現し、 2つの実装間でスプライシングを実行できるようにしました。このPRでは、 リモートファンディングキーのローテーションのサポート、コミットメント署名メッセージ用のbatch_sizeの追加、 パケットサイズ制限による以前のファンディングトランザクションの送信の防止、 メッセージからのブロックハッシュの削除、事前設定されたファンディングアウトプット残高の調整など、 Eclairの実装に合わせるためのいくつかの変更が導入されました。

  • Eclair #2935は、チャネルピアによって強制閉鎖が開始された場合の ノードオペレーターへのイベントの通知を追加しました。

  • LDK #3137は、ピアによって開始されたデュアルファンドチャネルを受け入れるサポートを追加しましたが、 そのようなチャネルへの資金提供や作成はまだサポートされていません。 manually_accept_inbound_channelsがfalseに設定されている場合、チャネルは自動的に受け入れられますが、 ChannelManager::accept_inbound_channel()関数では手動で受け入れることができます。 デュファルファンドチャネルと非デュファルファンドチャネルのインバウンド要求を区別するために、 新しいchannel_negotiation_typeフィールドが導入されました。 ゼロ承認デュアルファンドチャネルと、 ファンディングトランザクションのRBFによる手数料の引き上げはサポートされていません。

  • LND #8337は、LNDでイベント駆動型のプロトコル有限状態マシン(FSM)を作成するための再利用可能なフレームワークである protofsmパッケージを導入しました。状態、遷移、イベントを処理するための定型的なコードを書く代わりに、 開発者は状態、イベントをトリーがするもの、それらの間を移動するためのルールを定義することができ、 Stateインターフェースは動作をカプセル化し、イベントを処理し、終端状態を決定します。 一方、デーモンアダプターは、トランザクションのブロードキャストやピアメッセージの送信などの副作用を処理します。