silent payments: integrate SPDK scanning and wallet IPC by pzafonte · Pull Request #50 · kernel-node/kernel-node

pzafonte · 2026-05-02T15:16:46Z

New PR using SPDK... Integrate BIP-352 silent payment scanning into kernel-node using the silentpayments crate from SPDK.

Add crates/wallet as a workspace member with a silentpayments submodule that wraps SPDK's cryptographic primitives
Scan each accepted block for payments using kernel undo data to recover prevout scripts
Track received UTXOs and balance in an in-memory wallet
Expose import_keys, balance, and history over the existing node.sock

yancyribbens · 2026-05-04T16:29:55Z

Thanks for adding this. I'm surprised how much code there is still even with including SPDK. Although, I guess that's due to adding supporting wallet code. I'd also prefer that SPDK used rust-bitcoin-coin-selection since it seems more robust and has more supported selection algos, although my opinion is maybe a bit biased :P

pzafonte · 2026-05-07T19:28:41Z

Latest commits incorporate the most recent code reviews. Thanks!

yancyribbens · 2026-05-08T11:16:54Z

@pzafonte , im curious what you think about using SPDK now that you've completed PRs both with and without. Did you feel like the SPDK saved you a lot of work and effort vs the first PR you made? Im somewhat skeptical because both PRs seem to be similar in size.

yancyribbens · 2026-05-08T11:19:08Z

Latest commits incorporate the most recent code reviews. Thanks!

btw, this is still in Draft. Move it out of draft if you think it's a merge candidate.

pzafonte · 2026-05-08T12:01:40Z

@pzafonte , im curious what you think about using SPDK now that you've completed PRs both with and without. Did you feel like the SPDK saved you a lot of work and effort vs the first PR you made? Im somewhat skeptical because both PRs seem to be similar in size.

This was definitely much easier. W.R.T. size, it looks that way since I pushed up the spdk changes on the previous PR. Comparing just my original code (no test vectors), this PR is roughly ~1/3 the size. Much more maintainable, and we don't have to own the cryptography layer in this repo.

yancyribbens · 2026-05-08T12:37:09Z

and we don't have to own the cryptography layer in this repo.

However, I did notice there is a disclaimer we should keep in mind on the SPDK implementation:

SPDK currently relies on cryptography that is not professionally reviewed. Be mindful of this when using SPDK with real funds.

rustaceanrob · 2026-05-09T15:54:44Z

SPDK currently relies on cryptography that is not professionally reviewed. Be mindful of this when using SPDK with real funds

This will likely be delegated to secp once the C library has merged the API for silent payments.

rustaceanrob · 2026-05-09T19:19:46Z

    shutdown_tx: mpsc::Sender<()>,
    tip_state: &Arc<Mutex<TipState>>,
+    wallet_state: WalletState,
+    chainman_holder: Arc<std::sync::OnceLock<Arc<ChainstateManager>>>,


I had to remind myself of what OnceLock was. I'm not sure this is a great way to proceed. Have we tried using a std::sync::mpsc::channel? We can spawn a new thread that waits for blocks to scan when this callback is hit. So instead of scan_kernel_block here, we send the block over the channel to a consuming thread.

I tried using the channel, and replaced OnceLock with a consumer thread that looks up the entry via chainman.get_block_tree_entry(hash) after the callback returns. A round trip test showed get_block_tree_entry returns None for just-connected blocks, even from a separate thread, so the entry isn't available at this stage. read_spent_outputs(entry) has to happen synchronously where the entry is alive. Since the callback is registered before ChainstateManager exists, we need some kind of slot for chainman or if the kernel callback delivered spent outputs alongside the block that might work, I think. Open to alternatives if you can think of one, but OnceLock seems structurally required given the existing state of things.

As in we call send with the block and entry within with_block_connected_validation and the undo data is not present on the receiving thread? That seems strange if it is available within the callback.

Unless I'm missing something, to get the undo data you call chainman.read_spent_outputs(entry), and the receiving thread doesn't have a reference to chainman.

The receiving thread can clone the Arc cheaply once it starts up. I will push up a branch as a demo for what I'm thinking tomorrow. Other review can be addressed in the meantime.

So far I think you're right. Brutal. The self-referential nature of this architecture bothers me a lot but I think this is the only way to proceed. Confusing why the method returns None when it should return Some, at least at first glance.

rustaceanrob · 2026-05-10T08:13:39Z

+        }
+    };
+
+    let btc_block = kernel_block_to_bitcoin_block(kernel_block);


I think this is leaking some wallet logic to the node module, which we would like to keep as tidy as possible. It seems like we can refactor scan_block of the wallet to take kernel::Block and kernel spent outputs to move the entirety of the scanning logic to the wallet module.

rustaceanrob · 2026-05-11T10:00:26Z

@pzafonte do you mind if we pair program the rest, i.e. I force-push this branch? You'll still get commit attribution, just eager to move this along while I have the time.

pzafonte · 2026-05-11T10:44:18Z

@pzafonte do you mind if we pair program the rest, i.e. I force-push this branch? You'll still get commit attribution, just eager to move this along while I have the time.

I don't mind that, I just pushed up the latest changes that address the existing review.

rustaceanrob · 2026-05-11T12:12:18Z

+}
+
+#[derive(Debug, Clone)]
+pub struct OwnedUtxo {


For each coin we will need the following:

ScriptPubKey

OutPoint

A scalar representing the "tweak", should be returned at some point by scan_transaction

Amount

Label for change

Only the receiving side of silent payments is being added here, right? Isn't this struct something that should be provided by the SPDK framework?

fwiw, SPDK exposes the following for Receiver:

/// A struct representing a silent payment recipient. /// /// It can be used to scan for transaction outputs belonging to us by using the [`scan_transaction`](Receiver::scan_transaction) function. /// It optionally supports labels, which it manages internally. /// Labels can be added with [`add_label`](Receiver::add_label). #[derive(Debug, Clone, PartialEq)] pub struct Receiver { version: u8, scan_pubkey: PublicKey, spend_pubkey: PublicKey, change_label: Label, // To be able to tell which label is the change labels: BiMap<Label, PublicKey>, pub network: Network, }

yancyribbens · 2026-05-11T21:42:51Z

+};
+use secp256k1::{Scalar, SecretKey, XOnlyPublicKey};
+
+pub struct InputData {


Isn't this a TxIn? https://github.com/rust-bitcoin/rust-bitcoin/blob/0.32.x/bitcoin/src/blockdata/transaction.rs#L215

SPDK doesn't use bitcoin types so the conversion is unnecessary. That being said I think we can clean up the number of types introduced in this PR.

yancyribbens · 2026-05-11T21:49:32Z

+}
+
+#[derive(Debug, Clone)]
+pub struct FoundUtxo {


I believe this is TxOut with an added tweak and label: https://github.com/rust-bitcoin/rust-bitcoin/blob/0.32.x/bitcoin/src/blockdata/transaction.rs#L574

rustaceanrob · 2026-05-12T13:22:07Z

High level commit structure has good separation of concerns. I brainstormed a bit yesterday about final clean up for this PR if possible, here is my architectural feedback:

The distinction between Wallet and WalletState is not clear to me. I suggest we roll these into a single structure, Wallet. Within the WalletState, we have reference counted fields behind a mutex, but we should instead have a single Arc with a Mutex that locks the high level Wallet struct. This will minimize the heap allocations and make it clear at which points the wallet is being mutated.

It appears to me that we can also roll scan_block and Wallet::process_block into a single call. This makes the scope of where the wallet will be mutated to a single function call that we can evaluate. Having UTXOs be added after the block is "scanned" doesn't make much sense IMO.

We should probably try to avoid converting to a bitcoin::Block at all. We already process undo data directly from Core, it should be possible to check for taproot keys directly from the kernel::Block easily. Removing serialization roundtrips should be a top priority for us.

OwnedUTXO should just be called Coin.

We should also early-return in the callback functions of ContextBuilder if there is no wallet present.

rustaceanrob · 2026-05-13T19:34:04Z

Looking good. Does SPDK have tooling for generating the address? I'd like to give this a final smoke test by sending some signet coins.

yancyribbens · 2026-05-13T21:40:10Z

Does SPDK have tooling for generating the address?

https://github.com/cygnet3/spdk/blob/master/silentpayments/examples/create_wallet.rs

pzafonte · 2026-05-13T21:41:09Z

Looking good. Does SPDK have tooling for generating the address? I'd like to give this a final smoke test by sending some signet coins.

It has silentpayments::SilentPaymentAddress::new() I can write an example for deriving a silent payment address, and then write an end-to-end script to do the smoke test. Is there a better approach?

rustaceanrob · 2026-05-14T12:04:47Z

I would like to develop a more thoughtful approach of how we do testing here, likely taking some inspiration from Floresta. In the meantime, let's add a final method Receive that returns the SP address string with no label.

Add a workspace crate implementing BIP-352 silent payment scanning. Provides Wallet (UTXO tracking, balance, history), scan_transaction for detecting incoming payments, and build_receiver for constructing a Receiver from scan/spend keys.

Add scan_kernel_block registered via with_block_connected_validation so undo data is tied to the block being scanned. OnceLock provides ChainstateManager to the callback after construction. Expose wallet state over IPC via a makeWallet sub-client on the existing Server interface, with Receiver cached on import-keys.

…nce, and history Add receive generate-keys, import-keys, balance, and history subcommands under a wallet sub-command group. The IPC-bound subcommands reach the node via a single node.sock connection, calling makeWallet to obtain the wallet sub-client capability. generate-keys runs client-side only, generating keys from OsRng via bitcoin's rand-std feature.

rustaceanrob · 2026-05-15T12:07:17Z

Epic. I tested the flow and was able to receive a payment on signet. I have some follow-ups in mind to clean this up and potentially make it more performant, but this is a good start.

ACK fac0921

sedited · 2026-05-15T12:25:14Z

Nice! :D

pzafonte mentioned this pull request May 2, 2026

silent payments: integrate SPDK scanning and wallet IPC #47

Closed

rustaceanrob reviewed May 4, 2026

View reviewed changes

Comment thread capnp/wallet.capnp

rustaceanrob reviewed May 4, 2026

View reviewed changes

Comment thread src/bin/node.rs Outdated

rustaceanrob reviewed May 4, 2026

View reviewed changes

Comment thread src/bin/node.rs Outdated

rustaceanrob reviewed May 4, 2026

View reviewed changes

Comment thread src/bin/node.rs Outdated

Comment thread src/bin/node.rs Outdated

Comment thread src/peer.rs Outdated

Comment thread src/bin/node.rs

pzafonte force-pushed the silent-payments branch from e8ec66d to af29a15 Compare May 4, 2026 19:55

rustaceanrob reviewed May 6, 2026

View reviewed changes

Comment thread crates/wallet/src/silentpayments/scanning.rs Outdated

rustaceanrob reviewed May 6, 2026

View reviewed changes

Comment thread src/bin/node.rs Outdated

rustaceanrob reviewed May 6, 2026

View reviewed changes

Comment thread src/bin/node.rs Outdated

rustaceanrob reviewed May 6, 2026

View reviewed changes

Comment thread src/bin/node.rs Outdated

pzafonte force-pushed the silent-payments branch from af29a15 to 9c9e955 Compare May 6, 2026 22:36

rustaceanrob reviewed May 7, 2026

View reviewed changes

Comment thread crates/wallet/src/silentpayments/scanning.rs Outdated

rustaceanrob reviewed May 7, 2026

View reviewed changes

Comment thread crates/wallet/src/silentpayments/wallet.rs Outdated

rustaceanrob reviewed May 7, 2026

View reviewed changes

Comment thread src/ipc.rs Outdated

pzafonte force-pushed the silent-payments branch from 9c9e955 to 068f3ad Compare May 7, 2026 19:22

pzafonte marked this pull request as ready for review May 8, 2026 19:32

rustaceanrob reviewed May 9, 2026

View reviewed changes

Comment thread src/bin/cli.rs Outdated

rustaceanrob reviewed May 9, 2026

View reviewed changes

Comment thread src/bin/cli.rs Outdated

rustaceanrob reviewed May 9, 2026

View reviewed changes

Comment thread crates/wallet/src/silentpayments/wallet.rs Outdated

rustaceanrob reviewed May 9, 2026

View reviewed changes

rustaceanrob reviewed May 10, 2026

View reviewed changes

Comment thread src/bin/node.rs

rustaceanrob reviewed May 10, 2026

View reviewed changes

Comment thread Cargo.toml Outdated

pzafonte force-pushed the silent-payments branch from 068f3ad to f0d7c85 Compare May 11, 2026 10:41

rustaceanrob reviewed May 11, 2026

View reviewed changes

Comment thread src/ipc.rs Outdated

pzafonte force-pushed the silent-payments branch from f0d7c85 to 26204a8 Compare May 11, 2026 21:04

yancyribbens reviewed May 11, 2026

View reviewed changes

rustaceanrob reviewed May 12, 2026

View reviewed changes

Comment thread src/bin/cli.rs Outdated

pzafonte force-pushed the silent-payments branch from 26204a8 to 7040660 Compare May 13, 2026 12:16

rustaceanrob reviewed May 13, 2026

View reviewed changes

Comment thread src/bin/cli.rs

pzafonte force-pushed the silent-payments branch from 7040660 to b25ff9a Compare May 13, 2026 16:01

pzafonte added 3 commits May 14, 2026 12:45

pzafonte force-pushed the silent-payments branch from b25ff9a to fac0921 Compare May 14, 2026 16:46

rustaceanrob merged commit 24ef7bd into kernel-node:master May 15, 2026
1 check passed

Conversation

pzafonte commented May 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

yancyribbens commented May 4, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

pzafonte commented May 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

yancyribbens commented May 8, 2026

Uh oh!

yancyribbens commented May 8, 2026

Uh oh!

pzafonte commented May 8, 2026

Uh oh!

yancyribbens commented May 8, 2026

Uh oh!

rustaceanrob commented May 9, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

rustaceanrob May 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pzafonte May 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rustaceanrob May 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

rustaceanrob commented May 11, 2026

Uh oh!

pzafonte commented May 11, 2026

Uh oh!

rustaceanrob May 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

rustaceanrob commented May 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

pzafonte commented May 2, 2026 •

edited

Loading

pzafonte commented May 7, 2026 •

edited

Loading

rustaceanrob May 9, 2026 •

edited

Loading

pzafonte May 10, 2026 •

edited

Loading

rustaceanrob May 10, 2026 •

edited

Loading

rustaceanrob May 11, 2026 •

edited

Loading

rustaceanrob commented May 12, 2026 •

edited

Loading