You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
PR #784 adds -llmqdevnetparams=<size>:<threshold> support, which faithfully mirrors Dash Core's flag of the same name. In Dash Core, that flag only adjusts the size/threshold of LLMQ_DEVNET (type 101) — confirmed in chainparams.cpp:
auto params = std::ranges::find_if(consensus.llmqs, [](constauto& llmq){
return llmq.type == Consensus::LLMQType::LLMQ_DEVNET;}); // only 101
LLMQ_DEVNET_DIP0024 (105) and LLMQ_DEVNET_PLATFORM (107) keep their hardcoded defaults regardless of that flag.
The gap
Dash Core ships three companion flags that small devnets routinely rely on (declared in chainparams.cpp):
These don't change a quorum's size — they change which LLMQ type fulfills each role. The typical small-devnet recipe is to shrink LLMQ_DEVNET (via -llmqdevnetparams) to fit the masternode count, then reroute ChainLocks / InstantSend DIP24 / Platform onto it, because the default 105/107 quorums (8 and 12 members) can't form on a small MN set.
Consequence: an SPV client talking to a devnet started with, say, -llmqinstantsenddip0024=llmq_devnet will keep hunting for LlmqtypeDevnetDIP0024 quorums, find none, and silently fail to verify InstantSend locks. Same story for rerouted ChainLocks / Platform.
Proposed solution
Allow per-instance overrides of the four NetworkLLMQExt lookups on devnet, surfaced through ClientConfig and the CLI.
ClientConfig (dash-spv)
pubstructClientConfig{// ...publlmq_devnet_params:Option<LlmqDevnetParams>,// already in PR #784publlmq_chainlocks_type:Option<LLMQType>,// newpubllmq_instantsend_dip0024_type:Option<LLMQType>,// newpubllmq_platform_type:Option<LLMQType>,// new// (and a builder method for each — Devnet-only validation, same as llmq_devnet_params)}
Mirroring Dash Core's flag names. Quorum name strings should accept llmq_devnet, llmq_devnet_dip0024, llmq_devnet_platform at minimum (the set of LLMQ types valid on devnet).
Routing change
NetworkLLMQExt currently takes &self (a Network). The cleanest way to thread overrides through is to either:
Option A — add a NetworkLLMQContext { network: Network, overrides: DevnetRouting } and have callers use that instead of Network. Clean, but touches many call sites.
Option B — apply the same OnceLock global-override pattern PR feat: devnet support for dash-spv #784 introduced for LLMQ_DEVNET params: set_devnet_chainlocks_type(t), set_devnet_isd_type(t), set_devnet_platform_type(t). Smaller diff, idempotent contract is already established. Tradeoff: same process-global limitation as the existing override.
Option B is consistent with what's already there and probably the right pragmatic call.
Out of scope
Changes to mainnet/testnet/regtest routing — these flags are devnet-only in Dash Core.
Background
PR #784 adds
-llmqdevnetparams=<size>:<threshold>support, which faithfully mirrors Dash Core's flag of the same name. In Dash Core, that flag only adjusts the size/threshold ofLLMQ_DEVNET(type 101) — confirmed inchainparams.cpp:LLMQ_DEVNET_DIP0024(105) andLLMQ_DEVNET_PLATFORM(107) keep their hardcoded defaults regardless of that flag.The gap
Dash Core ships three companion flags that small devnets routinely rely on (declared in
chainparams.cpp):These don't change a quorum's size — they change which LLMQ type fulfills each role. The typical small-devnet recipe is to shrink
LLMQ_DEVNET(via-llmqdevnetparams) to fit the masternode count, then reroute ChainLocks / InstantSend DIP24 / Platform onto it, because the default 105/107 quorums (8 and 12 members) can't form on a small MN set.In
rust-dashcoretoday, the routing is hardcoded indash/src/sml/llmq_type/network.rs:Consequence: an SPV client talking to a devnet started with, say,
-llmqinstantsenddip0024=llmq_devnetwill keep hunting forLlmqtypeDevnetDIP0024quorums, find none, and silently fail to verify InstantSend locks. Same story for rerouted ChainLocks / Platform.Proposed solution
Allow per-instance overrides of the four
NetworkLLMQExtlookups on devnet, surfaced throughClientConfigand the CLI.ClientConfig(dash-spv)CLI (dash-spv binary)
Mirroring Dash Core's flag names. Quorum name strings should accept
llmq_devnet,llmq_devnet_dip0024,llmq_devnet_platformat minimum (the set of LLMQ types valid on devnet).Routing change
NetworkLLMQExtcurrently takes&self(aNetwork). The cleanest way to thread overrides through is to either:NetworkLLMQContext { network: Network, overrides: DevnetRouting }and have callers use that instead ofNetwork. Clean, but touches many call sites.OnceLockglobal-override pattern PR feat: devnet support fordash-spv#784 introduced forLLMQ_DEVNETparams:set_devnet_chainlocks_type(t),set_devnet_isd_type(t),set_devnet_platform_type(t). Smaller diff, idempotent contract is already established. Tradeoff: same process-global limitation as the existing override.Option B is consistent with what's already there and probably the right pragmatic call.
Out of scope
LLMQ_DEVNET— Dash Core itself doesn't expose those.Acceptance criteria
ClientConfigcarries the overrides through to startupchain_locks_type/isd_llmq_type/platform_typereturn the overridden values when setenabled_llmq_typesincludes the overridden typesdash-spv#784 test (test_llmq_devnet_override_lifecycle) stays greenReferences
chainparams.cpparg registration (search for-llmqchainlocks,-llmqinstantsenddip0024,-llmqplatform)dash-spv#784 — initial-llmqdevnetparamssupportdash-spv#784