kernel: Add function for creating chainparams with a signet challenge #35464

pull sedited wants to merge 2 commits into bitcoin:master from sedited:kernel_signet_challenge changing 4 files +33 −2

sedited commented at 2:43 PM on June 4, 2026: contributor

Adds a function for creating a chainparams with a signet challenge to the kernel API. This was requested in issue #35362.

Also takes this opportunity to de-noise the test kernel binary log output a bit.
kernel: Generate a signet with a challenge ae58debe70
test kernel: Don't log on warnings change 2ea7ac9aab
DrahtBot added the label Validation on Jun 4, 2026
DrahtBot commented at 2:43 PM on June 4, 2026: contributor



The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.



Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/35464.



Reviews

See the guideline for information on the review process.

Type Reviewers

ACK oleonardolima, edilmedeiros

Concept ACK stickies-v, w0xlt

If your review is incorrectly listed, please copy-paste <code></code> into the comment that the bot should ignore.
sedited added this to a project on Jun 4, 2026
github-project-automation[bot] changed the project status on Jun 4, 2026
sedited changed the project status on Jun 4, 2026
stickies-v commented at 10:44 AM on June 5, 2026: contributor

Concept ACK
edilmedeiros commented at 12:58 PM on June 5, 2026: contributor

Concept ACK

A better design would be a function btck_chain_parameters_set_signet_challenge that modifies an existing btck_ChainParameters created with btck_chain_parameters_create if it is indeed a signet structure.

I don't like having two functions in the API that can be used to initialize btck_ChainParameters. That might lead to API creeping just like adding parameters to btck_chain_parameters_create to account for test networks as mentioned in #35362 (comment) (e.g. adding support for something like #35335 for testing as well).

What I'm suggesting is probably harder to implement, though. Will put some time to test.
sedited commented at 1:46 PM on June 5, 2026: contributor

A better design would be a function btck_chain_parameters_set_signet_challenge that modifies an existing btck_ChainParameters created with btck_chain_parameters_create if it is indeed a signet structure.

That works too, but it seemed more confusing to allow setting a signet challenge for a non-signet chain.

I don't like having two functions in the API that can be used to initialize btck_ChainParameters. That might lead to API creeping just like adding parameters to btck_chain_parameters_create to account for test networks as mentioned in #35362 (comment) (e.g. adding support for something like #35335 for testing as well).

I don't think this will end up being very noisy. Any further parameters, like deployment bits, can just be added to these chain-type specific functions. Another reason I didn't implement it that way is that we instantiate the chainparams internally as const.
oleonardolima commented at 2:40 PM on June 5, 2026: none

cACK 2ea7ac9aabe6ce4c42fd45c841bf615464b558cc

I've added new draft methods to rust-bitcoinkernel to use the new btck_chain_parameters_create_signet, see: https://github.com/sedited/rust-bitcoinkernel/pull/192/changes/3b5017e41fc5b29fc2ac65410d348c371ce8c099.

I tested with this custom signet and it worked well, though the new APIs I added feel a bit odd.

cc @edilmedeiros @johnnyasantoss
DrahtBot requested review from stickies-v on Jun 5, 2026
edilmedeiros commented at 10:34 PM on June 5, 2026: contributor

That works too, but it seemed more confusing to allow setting a signet challenge for a non-signet chain.

Yeah, that would involve deciding what to do for error handling (perform no side effect, probably).

Another reason I didn't implement it that way is that we instantiate the chainparams internally as const.

I tried to implement an alternative method like I said, but it would involve exposing more methods on CChainParams, but I'm not sure that is the best approach.
w0xlt commented at 1:35 AM on June 6, 2026: contributor

Concept ACK
edilmedeiros commented at 4:13 PM on June 6, 2026: contributor

tACK 2ea7ac9aabe6ce4c42fd45c841bf615464b558cc with a small C program and this datadir.

By the way, we need more examples of how to use this library.

It still feels odd to me to have something like btck_context_options_set_chainparams that modifies a structure and a different pattern with btck_chain_parameters_create_signet. Not a blocker for me, though, as I'm not totally familiar with the design discussions so far.
sedited commented at 9:12 PM on June 6, 2026: contributor

By the way, we need more examples of how to use this library.

I host the header's documentation with a few C examples on https://thecharlatan.ch/kernel-docs/. The tracking issue #27587 links this and lists all the language bindings that I know of. The docs for the Rust crate for example are fairly complete: https://docs.rs/bitcoinkernel/latest/bitcoinkernel/ . The tracking issue also lists and contextualizes most of the larger work going on at the moment. I realize this is a bit all over the place, but I don't really have a better solution for organizing these things into a single visible place. I used to link the tracking issue and project board in every kernel-related PR, maybe that would be helpful to do again?
edilmedeiros commented at 2:28 PM on June 8, 2026: contributor

I host the header's documentation with a few C examples on https://thecharlatan.ch/kernel-docs.

What about bringing them upstream: https://github.com/edilmedeiros/bitcoin/pull/2/changes?

Better if the CI could check if these examples build against changes in the library. I'll check how that could be done.