Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Feature Request: Native BIP352 support in `hsmd` and enhanced `bcli` block fetching

オープン
  • 何か問題がありますか？
#9,336 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 2 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
42/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
静か
技術スタック
c
領域
backend, blockchain, cryptography

調査の方向性

まず libhsmd.c と hsm_control.c を読んで、既存のシード導出および署名インターフェースを理解し、次に bcli の getblock 実装とその RPC 公開を調べてください。BIP352 の導出および署名の要件を verbosity-3 によるブロック取得の要件とは分けて検討し、どちらもプラグインの現在の回避策なしで統合できることを確認してください。

索引モデルが issue の本文から書いたものです。

説明

Feature Request: Native BIP352 support in hsmd and enhanced bcli block fetching

The Issue

I have been developing an experimental/proof-of-concept Core Lightning plugin to introduce BIP352 (Silent Payments) support directly to CLN nodes. You can see the current progress here: aido/silentpayments.

To get this working as a Python plug-in, I had to make a few compromises that bypass CLN's standard architecture. As a result, the plugin is practically operating as a "shadow wallet" alongside Core Lightning, which is far from ideal. I'm opening this issue to see if it is possible to get native support for these requirements in future releases.

1. The hsmd derivation bottleneck

Because hsmd strictly (and rightly) locks away the master seed, the plugin currently cannot perform the necessary BIP352 ECDH tweaks or natively sign Silent Payment outputs.

The Workaround: I am using the makesecret RPC (with the tweak bip352_silent_payments) to deterministically derive a 32-byte secret, which I then use as the master seed for BIP32 inside the plugin.
The Consequence: This creates a non-standard derivation path and forces the plugin to act as a siloed "shadow wallet". If a user takes their 24-word CLN recovery phrase and imports it into a BIP352-compatible wallet (like Sparrow), it will not see these funds. The addresses are completely tethered to the plugin's makesecret sandbox, which is a major UX and security risk for users trying to recover funds.

2. The bcli verbosity limitation

For BIP352 block scanning, we need the prevout scriptPubKeys for all inputs to calculate the tweaks.

The Workaround: I have to use Python's subprocess to call bitcoin-cli getblock <hash> 3 directly.
The Consequence: I cannot use CLN's internal bcli plugin because it is heavily locked down (only exposing 5 hardcoded commands to the RPC) and its internal C code strictly hardcodes getblock to verbosity "0" (raw hex). Shelling out to bitcoin-cli is brittle and bypasses the node's native architecture.

Proposed solution

  1. Native BIP352 Support in hsmd: It would be great to see native BIP352 derivation paths, ECDH tweaks, and signing capabilities added to hsmd (specifically libhsmd.c / hsm_control.c). This would allow plugins to request Silent Payment addresses and signatures securely, integrating properly with the main node rather than acting as a disjointed shadow wallet.
  2. Verbosity "3" Support in bcli: Either allow bcli's getblock command to accept a verbosity parameter (specifically level 3) so plugins can retrieve full transaction details with prevout data, or expose a more flexible RPC pass-through for bitcoind.

Additional context

Why BIP352 for Core Lightning?

Lightning node operators frequently need to share a static on-chain address; whether for node donations, liquidity management, submarine swaps, or out-of-band channel funding. Currently, doing so may compromise on-chain privacy, as chain surveillance can easily link a public Lightning Node ID to an entire UTXO history.

Bringing BIP352 to CLN allows operators to publish a single, reusable static address that preserves their privacy. Adding native hooks for BIP352 would make it easier for the plugin ecosystem to build out these advanced privacy features without requiring users to run modified C code or risk their funds in sandbox workarounds.

主要言語
C
スター
3.1k
フォーク
1k
平均マージ
4日 2時間
マージ済み PR（30日）
45

環境構築

  • Dockerfile または Docker Compose ファイルあり
  • プルリクエストのテンプレートあり
  • コントリビューションガイドなし

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

ElementsProject/lightning のほかの issue

ElementsProject/lightning の issue をすべて見る

似ている issue

C の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。