Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#9,336 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
42/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
c
Ambito
backend, blockchain, cryptography

Direzione di ricerca

Inizia leggendo libhsmd.c e hsm_control.c per comprendere le interfacce esistenti per la derivazione del seed e la firma, quindi esamina l’implementazione di getblock di bcli e la sua esposizione tramite RPC. Definisci separatamente i requisiti di derivazione e firma di BIP352 e quelli per il recupero dei blocchi con verbosity-3, e conferma che entrambi possono essere integrati senza gli attuali workaround del plugin.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
C
Stelle
3.1k
Fork
1k
Merge medio
3g 7h
PR unite (30g)
42

Preparare l'ambiente

  • Include un Dockerfile o un file Docker Compose
  • Ha un modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di ElementsProject/lightning

Tutte le issue di ElementsProject/lightning

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.