BIP352 Silent Payments (send) feature

[Talej]

Some justification around certain decisions:

Why a separate container for SP?

Currently silent payment PRs for bitcoin core are unmerged. Opted for separate silent payment sending functionality rather than using the unmerged PRs so we can remain with a standard bitcoin core build.

Once the silent payment PRs are merged we can switch to using the bitcoin core approach.

Why part of cyphernode rather than a separate cypherapp?

To generate a receive address we need to access the PK of the sending wallet. The sp container uses bitcoin RPC to do this. Thus it should only be part of cyphernodenet network.

Why sqlite db?

To keep sp lightweight and separate from the main cyphernode postgres db a small sqlite db was used for storing sp specific address watch data.

Some things to watch out for:

• If spend is used while a sp spend is in progress it is possible that spend will steal the UTXO(s) the sp spend is planning to use. We currently have no UTXO locking in place.

• The UTXO selection in here is currently quite dumb. May need to look at adding more logical selection for optimal results.

[BullishNode]

Thanks for the SP implementation. I think the remaining issues are mostly
around the new SP send path and making the deployment assumptions explicit.

Main things I’d fix before merge:

1. SP send failures should propagate as failures through the proxy.

   sp_spend calls the SP service with curl, but a non-2xx HTTP response
   from the SP service can still produce a zero shell return code. The proxy can
   then return HTTP 200 with an error body.

   That makes the transport contract ambiguous for callers. Please make the SP
   proxy helper map non-2xx SP service responses to a nonzero proxy return code,
   or otherwise preserve the upstream failure status consistently.

2. After broadcast, errors should not be returned as a generic send
   failure.

   In send-sp.ts, once sendrawtransaction returns a txid, the transaction
   may already be in the mempool. If self-verification, DB logging, or watch
   updates fail after that, returning a generic SEND_FAILED is risky because
   the caller cannot tell whether the payment happened.

   I’d split the send flow into pre-broadcast errors vs post-broadcast
   recovery/idempotency. Once a txid exists, return or persist that txid in a way
   that callers can safely reconcile.

3. Clarify the Bitcoin deployment requirement for SP.

   The SP compose service has depends_on: bitcoin. That is correct if SP is
   only supported with Cyphernode’s internal Bitcoin service.

   If that is the intended requirement, the installer/schema should enforce it
   so users cannot select SP with external Bitcoin mode.

   If SP is meant to work with external Bitcoin mode too, then depends_on: bitcoin needs to be conditional because the external Bitcoin node is not a
   compose service in this file.

Smaller follow-ups:

• Callback POST failures are currently swallowed, then the watch can be marked
  called/deactivated. That can permanently lose SP watch notifications.
• Pending watches are activated before signing/broadcast. If a later step
  fails, stale derived-address state can remain.
• The SP wallet parameter should either follow the existing Cyphernode
  wallet selector convention or explicitly reject unsupported raw wallet names.