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
- 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.
- 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.
Feature Request: Native BIP352 support in
hsmdand enhancedbcliblock fetchingThe 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
hsmdderivation bottleneckBecause
hsmdstrictly (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
makesecretRPC (with the tweakbip352_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
makesecretsandbox, which is a major UX and security risk for users trying to recover funds.2. The
bcliverbosity limitationFor BIP352 block scanning, we need the
prevoutscriptPubKeysfor all inputs to calculate the tweaks.The Workaround: I have to use Python's
subprocessto callbitcoin-cli getblock <hash> 3directly.The Consequence: I cannot use CLN's internal
bcliplugin because it is heavily locked down (only exposing 5 hardcoded commands to the RPC) and its internal C code strictly hardcodesgetblockto verbosity "0" (raw hex). Shelling out tobitcoin-cliis brittle and bypasses the node's native architecture.Proposed solution
hsmd: It would be great to see native BIP352 derivation paths, ECDH tweaks, and signing capabilities added tohsmd(specificallylibhsmd.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.bcli: Either allowbcli'sgetblockcommand to accept a verbosity parameter (specifically level 3) so plugins can retrieve full transaction details withprevoutdata, or expose a more flexible RPC pass-through forbitcoind.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.