backport: merge bitcoin#25153, #25113, #25249, #25369, #25617, #25611, #25736, #25714, #26612, #27605, #30464, partial bitcoin#25551 (univalue backports) #6775

kwvg · 2025-07-23T07:09:45Z

Motivation

To get rid of the -Wdangling-reference suppression (source) for GCC introduced in dash#6639 by backporting the set of changes needed to backport bitcoin#27605.

Additional Information

At some point, the contents on univalue/ diverged from official repository (bitcoin-core/univalue-subtree), which makes updating the subtree a more difficult prospect.

We realign the subtree by updating it to a44caf65 (last sane commit, taken from bitcoin#22646, which was backported as dash#4823) and marking all merge conflicts in favour of the incoming update. This lets us do the final few subtree updates before it's no longer treated as a subtree.
To allow for subtree updates, bitcoin#25464 (backported as 001d7ba in dash#6698) was temporarily reverted and then reapplied after the directory was unsubtree'd.
bitcoin#30464 needed to be backported to keep the whitespace linter happy (failed build).

Breaking Changes

None expected.

Checklist

I have performed a self-review of my own code
I have commented my code, particularly in hard-to-understand areas (note: N/A)
I have added or updated relevant unit/integration/functional/e2e tests
I have made corresponding changes to the documentation (note: N/A)
I have assigned this pull request to a milestone (for repository code-owners and collaborators only)

…n listtransactions) reverts: - 001d7ba.

a44caf65fe Merge bitcoin-core/univalue-subtree#28: Import fixes for sanitizer reported issues 135254331e Import fixes for sanitizer reported issues d5fb86940e refactor: use c++11 range based for loop in checkObject ff9c379304 refactor: Use nullptr (c++11) instead of NULL 08a99754d5 build: use ax_cxx_compile_stdcxx.m4 to check for C++11 support 66d3713ce7 Merge bitcoin-core/univalue-subtree#29: ci: travis -> cirrus 808d487292 ci: travis -> cirrus c390ac375f Merge bitcoin-core/univalue-subtree#19: Split sources for easier buildsystem integration 4a5b0a1c65 build: Move source entries out to sources.mk 6c7d94b33c build: cleanup wonky gen usage a222637c6d Merge dashpay#23: Merge changes from jgarzik/univalue@1ae6a23 98fadc0909 Merge dashpay#24: Push bool into array correctly 5f03f1f39a Push bool into array correctly f77d0f718d Merge commit '1ae6a231a0169938eb3972c1d48dd17cba5947e1' into HEAD 98261b1 Merge dashpay#22: Clamp JSON object depth to PHP limit 54c4015 Clamp JSON object depth to PHP limit 5a58a46 Merge dashpay#21: Remove hand-coded UniValue destructor. b4cdfc4 Remove hand-coded UniValue destructor. 1ae6a231a0 Merge pull request dashpay#57 from MarcoFalke/test_fix 92bdd11f0b univalue_write: remove unneeded sstream.h include ffb621c130 Merge pull request dashpay#56 from drodil/remove_sstream_header f33acf9fe8 Merge commit '7890db9~' into HEAD 7fba60b Merge dashpay#17: [docs] Update readme 4577454 Merge dashpay#13: Fix typo 66e0adec4d Remove unnecessary sstream header from univalue.h ac7e73c [docs] Update readme 7890db9 Merge dashpay#11: Remove deprecated std pair wrappers 88967f6586 Version 1.0.4 40e3485 Merge dashpay#14: Cleaned up namespace imports to reduce symbol collisions 1dc113dbef Merge pull request dashpay#50 from luke-jr/pushKV_bool 72392fb227 [tests] test pushKV for boolean values c23132bcf4 Pushing boolean value to univalue correctly 4a49647 Fix typo 85052a4 Remove deprecated std::pair wrappers 81faab26a1 Merge pull request dashpay#48 from fwolfst/47-UPDATE_MIT_LINK_TO_HTTPS b17634ef24 Update URLs to MIT license. 51d3ab3 Merge dashpay#10: Add pushKV(key, boolean) function (replaces dashpay#5) 129bad9 [tests] test pushKV for boolean values b3c44c9 Pushing boolean value to univalue correctly 07947ff Merge dashpay#9: [tests] Fix BOOST_CHECK_THROW macro ec849d9 [tests] Fix BOOST_CHECK_THROW macro 88ab64f6b5 Merge pull request dashpay#46 from jasonbcox/master 35ed96da31 Merge pull request dashpay#44 from MarcoFalke/Mf1709-univalue-cherrypick-explicit 420c226290 Merge pull request dashpay#45 from MarcoFalke/Mf1710-univalue-revert-test d208f98 Cleaned up namespace imports to reduce symbol collisions 31bc9f5 Merge dashpay#8: Remove unused Homebrew workaround fa04209 Remove HomeBrew workaround a523e08 Merge dashpay#7: Declare single-argument (non-converting) constructors "explicit" a9e53b3 Merge dashpay#4: Pull upstream fe805ea Declare single-argument (non-converting) constructors "explicit" 8a2d6f1 Merge pull request dashpay#41 from jgarzik/get-obj-map ba341a2 Add getObjMap() helper method. Also, constify checkObject(). ceb1194 Handle .pushKV() and .checkObject() edge cases. 107db98 Add ::push_back(double) method for feature parity. d415300 Move one-line implementation of UniValue::read() to header. 52e85b3 Move exception-throwing get_* methods into separate implementation module. dac5296 README.md: update code quotes 3e31dcf README.md: close code quote d09b842 Update README.md f1b86ed Convert README to markdown style. 1dfe464 Import UniValue class unit tests from bitcoin project. 0d3e74d operator[] takes size_t index parameter (versus unsigned int) 640158f Private findKey() method becomes size_t clean, and returns bool on failure. 7099135 Merge pull request dashpay#36 from ryanofsky/pr/end-str a31231b Version 1.0.3 4fd5444 Reject unterminated strings 81eba33 Merge pull request dashpay#26 from isle2983/pushBackHelpers 3640541 Merge PR dashpay#32 from branch 'nul-not-special' of git://github.com/ryanofsky/univalue into merge 89bb073 Merge pull request dashpay#31 from ryanofsky/raw-literals 511008c Merge pull request dashpay#30 from ryanofsky/test-driver 77974f3 Merge pull request dashpay#34 from paveljanik/20161116_Wshadow_codepoint a38fcd3 Do not shadow member variable codepoint. fd32d1a Don't require nul-terminated string inputs 0bb1439 Support parsing raw literals in UniValue 28876d0 Merge pull request dashpay#29 from btcdrak/exportspace 839ccd7 Add test driver for JSONTestSuite 26ef3ff Remove trailing whitespace from JSON export 16a1f7f Merge dashpay#3: Pull upstream 3f03bfd Merge pull request dashpay#27 from laanwj/2016_09_const_refs 5668ca3 Return const references from getKeys, getValues, get_str cedda14 Merge pull request dashpay#28 from MarcoFalke/patch-1 9f0b997 [travis] Work around osx libtool issue daf1285 Merge pull request dashpay#2 from jgarzik/master cfa0384 Convenience wrappers for push_back-ing integer types d9e62d3 Merge pull request dashpay#24 from MarcoFalke/Mf1608-cleanup faf260f Rem unused vars and prefer prefix operator for non-primitive type 09a2693 Merge pull request dashpay#22 from laanwj/2016_04_unicode c74a04c Merge pull request dashpay#23 from paveljanik/20160527_Wshadow f32df99 Merge branch '2016_04_unicode' into bitcoin 280b191 Merge remote-tracking branch 'jgarzik/master' into bitcoin fceb4f8 Do not shadow variables c9a716c Handle UTF-8 bed8dd9 Version 1.0.2. 5e7985a Merge pull request dashpay#14 from laanwj/2015_11_escape_plan git-subtree-dir: src/univalue git-subtree-split: a44caf65fe55b9dd8ddb08f04c0f70409efd53b3

as b1ae6f5

as 88f794f

6c19d050a9 Merge bitcoin-core/univalue-subtree#33: Add getInt<Integral>() helper 09e4a930fc Add getInt helper 10619e0d9a Merge bitcoin-core/univalue-subtree#32: refactor: include-what-you-use 431cdf5d27 refactor: use constexpr where appropriate 64fc881fa4 refactor: cleanup headers for iwyu 9c35bf38eb Merge bitcoin-core/univalue-subtree#30: doc: note that our API has diverged from upstream 09b65facb9 doc: note that our API has diverged from upstream git-subtree-dir: src/univalue git-subtree-split: 6c19d050a9bcb2be216121db0df57c930a9ee12e

Fulfilled by 774a8ff

de4f73ddca Merge bitcoin-core/univalue-subtree#36: Drop overloaded members 076c051488 Drop overloaded members 06265321de Merge bitcoin-core/univalue-subtree#35: Remove get_int/get_int64 in favor of getInt<> 462c503aa4 Remove get_int/get_int64 in favor of getInt<> 68c8f5532d Merge bitcoin-core/univalue-subtree#34: doc: remove TODO 297c53a5ee doc: remove TODO git-subtree-dir: src/univalue git-subtree-split: de4f73ddca40487179e9ed08c6f6aa745d6cbba3

as b3443ee

Fulfilled by c0c3af9

…usage in listtransactions) reverts: - 780961a6152ccb109f9c51bf54dd7209df9b8f6.

…r silent ignore excludes: - ccccc17 (impacts code that is SegWit-specific)

…pe confusions

…::find_value method

github-actions · 2025-07-23T07:28:57Z

⚠️ Potential Merge Conflicts Detected

This PR has potential conflicts with the following open PRs:

feat: implement Platform Ban PoSe DIP-0031 #6613 - feat: implement Platform Ban PoSe DIP-0031

Please coordinate with the authors of these PRs to avoid merge conflicts.

…ble"

coderabbitai · 2025-07-23T09:51:13Z

Walkthrough

This set of changes removes the UniValue library as a subtree and fully integrates it into the main repository. All subtree references, build scripts, configuration files, and documentation related to UniValue as an external or semi-external component are deleted or updated. The UniValue codebase is modernized: its API is refactored to use C++17 features such as std::string_view, template-based type-safe getters (getInt<T>() replaces get_int()/get_int64()), and exception-based error handling replaces boolean error returns. Numerous method signatures and behaviors are updated to reflect these changes. All code in the repository that interacts with UniValue is updated to use the new API, with corresponding changes to tests, RPC handlers, wallet code, and utility functions. Linting and test scripts are adjusted to include the now-integrated UniValue code. UniValue-specific tests are refactored for the new API and to remove Boost dependencies. All build system and CI files specific to the UniValue subtree are deleted.

Estimated code review effort

5 (~180 minutes)
This is a large, high-complexity change affecting many core files, public APIs, tests, build systems, and repository organization. It requires careful review to ensure correctness, compatibility, and that all usages of the UniValue API are updated consistently throughout the codebase.

✨ Finishing Touches

📝 Generate Docstrings

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

Review comments: Directly reply to a review comment made by CodeRabbit. Example:
- I pushed a fix in commit <commit_id>, please review it.
- Explain this complex logic.
- Open a follow-up GitHub issue for this discussion.
Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
- @coderabbitai explain this code block.
- @coderabbitai modularize this function.
PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
- @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
- @coderabbitai read src/utils.ts and explain its main purpose.
- @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
- @coderabbitai help me debug CodeRabbit configuration file.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

@coderabbitai pause to pause the reviews on a PR.
@coderabbitai resume to resume the paused reviews.
@coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
@coderabbitai full review to do a full review from scratch and review all the files again.
@coderabbitai summary to regenerate the summary of the PR.
@coderabbitai generate docstrings to generate docstrings for this PR.
@coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
@coderabbitai resolve resolve all the CodeRabbit review comments.
@coderabbitai configuration to show the current CodeRabbit configuration for the repository.
@coderabbitai help to get help.

Other keywords and placeholders

Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (`.coderabbit.yaml`)

You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
Please see the configuration documentation for more information.
If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

Visit our Documentation for detailed information on how to use CodeRabbit.
Join our Discord Community to get help, request features, and share feedback.
Follow us on X/Twitter for updates and announcements.

coderabbitai

Actionable comments posted: 6

🔭 Outside diff range comments (4)

src/wallet/rpc/wallet.cpp (2)
110-116: Add explicit RPCTypeCheckArgument before using getInt()

getInt<int>() will now throw a std::runtime_error on non-numeric input, but the resulting error message will be a generic UniValue parse failure instead of the wallet-RPC–style "Invalid parameter" we emit elsewhere. For consistency with the rest of the RPC codebase (e.g. lockunspent, listunspent, upgradewallet) insert an explicit type check before extracting the value:
+    RPCTypeCheckArgument(request.params[0], UniValue::VNUM);
     int nRounds = request.params[0].getInt<int>();
This keeps the error surface homogeneous and avoids leaking UniValue exception text to API users.

141-147: Mirror the argument validation pattern used elsewhere

Same rationale as above: add a type check for amount so that callers receive a predictable RPC error instead of a UniValue exception.
+    RPCTypeCheckArgument(request.params[0], UniValue::VNUM);
     int nAmount = request.params[0].getInt<int>();
src/wallet/rpc/coins.cpp (1)
636-646: Prevent sign/size mismatches for maximumCount and coinType

maximumCount
Parsing into a signed 64-bit integer and then assigning to an unsigned uint64_t means a negative user input will wrap to an enormous positive value. Validate before assignment:
-            nMaximumCount = options["maximumCount"].getInt<int64_t>();
+            int64_t mc = options["maximumCount"].getInt<int64_t>();
+            if (mc < 0) {
+                throw JSONRPCError(RPC_INVALID_PARAMETER, "maximumCount cannot be negative");
+            }
+            nMaximumCount = static_cast<uint64_t>(mc);
coinType
Using int64_t is fine, but the subsequent cast to the enum class CoinType should stay type-safe. Consider storing directly into an int to avoid the implicit narrowing from 64-bit.

These small guards avoid UB and make the RPC behaviour deterministic.
src/rpc/governance.cpp (1)

1028-1055: Fix clang-format issues

The pipeline indicates clang format differences in this section. Please run clang-format to fix the formatting issues and ensure consistent code style.

♻️ Duplicate comments (1)

src/univalue/test/test_json.cpp (1)

7-10: Same vendored dependency concern as previous file.

This file is also under src/univalue/ which is listed as a restricted vendored dependency in the coding guidelines. The header changes appear consistent with the UniValue modernization, but please refer to the verification request in the previous file regarding whether UniValue is still considered vendored.

🧹 Nitpick comments (5)

src/rpc/rawtransaction.cpp (1)

264-268: Factor duplicated verbose-flag parsing into a small helper.

The exact isNum() ? getInt<int>() != 0 : get_bool() logic appears twice (getrawtransaction and getrawtransactionmulti).
Extracting this into a short static bool ParseVerboseFlag(const UniValue&) would:

prevent divergence if one site is ever tweaked,

cut two branches from the hot path,

improve readability.

No behaviour change, just DRY.

src/rpc/blockchain.cpp (1)

1653-1655: Parameter range checks missing for count / branchlen

getInt<int>() is fed straight into nCountMax and nBranchMin without validation.
Negative count yields undefined behaviour in the subsequent loop. Add the same non-negative validation used elsewhere.
src/univalue/test/unitester.cpp (1)
36-38: Consider simplifying boolean assertions.

While explicit comparisons work, the standard pattern is more concise:
         if (wantPass) {
-            assert(testResult == true);
+            assert(testResult);
         } else {
-            assert(testResult == false);
+            assert(!testResult);
         }
src/wallet/rpc/backup.cpp (1)
798-802: Prefer explicit 32-bit height type

Block heights are already handled as 32-bit (int32_t tip_height).
Keeping the same width for nStartHeight avoids silent narrowing/extension and documents the expected range more clearly.
-    int nStartHeight = 0;
+    int32_t nStartHeight = 0;

-        nStartHeight = request.params[1].getInt<int>();
+        nStartHeight = request.params[1].getInt<int32_t>();
src/wallet/rpc/coins.cpp (1)
332-334: Use unsigned int for vout to match tx-output indices

nOutput is stored as int, whereas COutPoint::n and CTVout indices are unsigned int. Although you check for nOutput < 0, switching to the unsigned type removes the need for this guard and eliminates a signed/unsigned comparison later on.
-        const int nOutput{o.find_value("vout").getInt<int>()};
+        const unsigned int nOutput{o.find_value("vout").getInt<unsigned int>()};

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between f648039 and 05e2091.

⛔ Files ignored due to path filters (1)

src/univalue/gen/gen.cpp is excluded by !**/gen/**

📒 Files selected for processing (92)

.gitignore (0 hunks)
Makefile.am (0 hunks)
ci/lint/06_script.sh (0 hunks)
ci/test/wrap-wine.sh (1 hunks)
configure.ac (1 hunks)
contrib/devtools/copyright_header.py (0 hunks)
doc/developer-notes.md (0 hunks)
src/Makefile.test.include (1 hunks)
src/bitcoin-cli.cpp (10 hunks)
src/bitcoin-tx.cpp (1 hunks)
src/coinjoin/options.cpp (1 hunks)
src/core_write.cpp (2 hunks)
src/evo/core_write.cpp (6 hunks)
src/evo/deterministicmns.cpp (1 hunks)
src/governance/classes.cpp (1 hunks)
src/governance/governance.cpp (2 hunks)
src/governance/object.cpp (1 hunks)
src/governance/validators.cpp (1 hunks)
src/httprpc.cpp (2 hunks)
src/llmq/commitment.h (1 hunks)
src/masternode/meta.cpp (1 hunks)
src/net_types.cpp (2 hunks)
src/node/interfaces.cpp (1 hunks)
src/qt/governancelist.cpp (1 hunks)
src/qt/rpcconsole.cpp (2 hunks)
src/rpc/blockchain.cpp (17 hunks)
src/rpc/client.cpp (4 hunks)
src/rpc/client.h (2 hunks)
src/rpc/governance.cpp (4 hunks)
src/rpc/masternode.cpp (1 hunks)
src/rpc/mempool.cpp (1 hunks)
src/rpc/mining.cpp (7 hunks)
src/rpc/net.cpp (7 hunks)
src/rpc/node.cpp (11 hunks)
src/rpc/output_script.cpp (1 hunks)
src/rpc/quorums.cpp (6 hunks)
src/rpc/rawtransaction.cpp (3 hunks)
src/rpc/rawtransaction_util.cpp (6 hunks)
src/rpc/request.cpp (3 hunks)
src/rpc/server.cpp (1 hunks)
src/rpc/util.cpp (7 hunks)
src/test/blockfilter_tests.cpp (1 hunks)
src/test/fuzz/rpc.cpp (1 hunks)
src/test/key_io_tests.cpp (2 hunks)
src/test/rpc_tests.cpp (13 hunks)
src/test/sighash_tests.cpp (1 hunks)
src/test/system_tests.cpp (2 hunks)
src/test/transaction_tests.cpp (2 hunks)
src/univalue/.cirrus.yml (0 hunks)
src/univalue/COPYING (0 hunks)
src/univalue/Makefile.am (0 hunks)
src/univalue/README.md (0 hunks)
src/univalue/TODO (0 hunks)
src/univalue/autogen.sh (0 hunks)
src/univalue/build-aux/m4/.gitignore (0 hunks)
src/univalue/build-aux/m4/ax_cxx_compile_stdcxx.m4 (0 hunks)
src/univalue/configure.ac (0 hunks)
src/univalue/include/univalue.h (4 hunks)
src/univalue/include/univalue_escapes.h (2 hunks)
src/univalue/include/univalue_utffilter.h (6 hunks)
src/univalue/lib/univalue.cpp (6 hunks)
src/univalue/lib/univalue_get.cpp (1 hunks)
src/univalue/lib/univalue_read.cpp (1 hunks)
src/univalue/lib/univalue_write.cpp (1 hunks)
src/univalue/pc/libunivalue-uninstalled.pc.in (0 hunks)
src/univalue/pc/libunivalue.pc.in (0 hunks)
src/univalue/sources.mk (1 hunks)
src/univalue/test/.gitignore (0 hunks)
src/univalue/test/no_nul.cpp (0 hunks)
src/univalue/test/object.cpp (10 hunks)
src/univalue/test/test_json.cpp (1 hunks)
src/univalue/test/unitester.cpp (3 hunks)
src/util/settings.h (1 hunks)
src/util/system.cpp (1 hunks)
src/wallet/rpc/addresses.cpp (2 hunks)
src/wallet/rpc/backup.cpp (5 hunks)
src/wallet/rpc/coins.cpp (5 hunks)
src/wallet/rpc/encrypt.cpp (1 hunks)
src/wallet/rpc/spend.cpp (2 hunks)
src/wallet/rpc/transactions.cpp (4 hunks)
src/wallet/rpc/wallet.cpp (5 hunks)
src/wallet/test/wallet_tests.cpp (2 hunks)
test/lint/README.md (0 hunks)
test/lint/lint-files.py (1 hunks)
test/lint/lint-format-strings.py (1 hunks)
test/lint/lint-include-guards.py (0 hunks)
test/lint/lint-includes.py (0 hunks)
test/lint/lint-locale-dependence.py (0 hunks)
test/lint/lint-shell-locale.py (1 hunks)
test/lint/lint-shell.py (1 hunks)
test/lint/lint-spelling.py (1 hunks)
test/lint/lint-whitespace.py (0 hunks)

📓 Path-based instructions (5)

src/**/*.{cpp,h,cc,cxx,hpp}

📄 CodeRabbit Inference Engine (CLAUDE.md)

src/**/*.{cpp,h,cc,cxx,hpp}: Dash Core C++ codebase must be written in C++20 and require at least Clang 16 or GCC 11.1
Dash uses unordered_lru_cache for efficient caching with LRU eviction

Files:

src/test/blockfilter_tests.cpp
src/llmq/commitment.h
src/test/system_tests.cpp
src/univalue/include/univalue_escapes.h
src/core_write.cpp
src/test/sighash_tests.cpp
src/wallet/rpc/encrypt.cpp
src/masternode/meta.cpp
src/evo/core_write.cpp
src/univalue/lib/univalue_read.cpp
src/bitcoin-tx.cpp
src/test/fuzz/rpc.cpp
src/governance/object.cpp
src/governance/validators.cpp
src/univalue/test/test_json.cpp
src/net_types.cpp
src/wallet/rpc/spend.cpp
src/test/key_io_tests.cpp
src/governance/classes.cpp
src/rpc/rawtransaction_util.cpp
src/util/system.cpp
src/rpc/server.cpp
src/rpc/masternode.cpp
src/univalue/test/unitester.cpp
src/rpc/request.cpp
src/util/settings.h
src/rpc/util.cpp
src/wallet/rpc/addresses.cpp
src/httprpc.cpp
src/node/interfaces.cpp
src/rpc/mempool.cpp
src/qt/governancelist.cpp
src/qt/rpcconsole.cpp
src/univalue/lib/univalue_write.cpp
src/rpc/output_script.cpp
src/wallet/rpc/coins.cpp
src/rpc/blockchain.cpp
src/wallet/rpc/wallet.cpp
src/rpc/governance.cpp
src/rpc/mining.cpp
src/rpc/client.h
src/univalue/lib/univalue_get.cpp
src/test/rpc_tests.cpp
src/test/transaction_tests.cpp
src/rpc/quorums.cpp
src/evo/deterministicmns.cpp
src/rpc/net.cpp
src/bitcoin-cli.cpp
src/univalue/include/univalue_utffilter.h
src/wallet/rpc/transactions.cpp
src/coinjoin/options.cpp
src/governance/governance.cpp
src/rpc/node.cpp
src/rpc/rawtransaction.cpp
src/rpc/client.cpp
src/univalue/lib/univalue.cpp
src/wallet/test/wallet_tests.cpp
src/wallet/rpc/backup.cpp
src/univalue/include/univalue.h
src/univalue/test/object.cpp

src/{test,wallet/test,qt/test}/**/*.{cpp,h,cc,cxx,hpp}

📄 CodeRabbit Inference Engine (CLAUDE.md)

Unit tests for C++ code should be placed in src/test/, src/wallet/test/, or src/qt/test/ and use Boost::Test or Qt 5 for GUI tests

Files:

src/test/blockfilter_tests.cpp
src/test/system_tests.cpp
src/test/sighash_tests.cpp
src/test/fuzz/rpc.cpp
src/test/key_io_tests.cpp
src/test/rpc_tests.cpp
src/test/transaction_tests.cpp
src/wallet/test/wallet_tests.cpp

src/{crc32c,dashbls,gsl,immer,leveldb,minisketch,secp256k1,univalue}/**

📄 CodeRabbit Inference Engine (CLAUDE.md)

Do not make changes under any circumstances to vendored dependencies in src/crc32c, src/dashbls, src/gsl, src/immer, src/leveldb, src/minisketch, src/secp256k1, src/univalue

Files:

src/univalue/include/univalue_escapes.h
src/univalue/lib/univalue_read.cpp
src/univalue/test/test_json.cpp
src/univalue/test/unitester.cpp
src/univalue/lib/univalue_write.cpp
src/univalue/lib/univalue_get.cpp
src/univalue/sources.mk
src/univalue/include/univalue_utffilter.h
src/univalue/lib/univalue.cpp
src/univalue/include/univalue.h
src/univalue/test/object.cpp

ci/**

📄 CodeRabbit Inference Engine (CLAUDE.md)

Unless specifically prompted, avoid making changes to the ci directory (continuous integration)

Files:

ci/test/wrap-wine.sh

src/{masternode,evo}/**/*.{cpp,h,cc,cxx,hpp}

📄 CodeRabbit Inference Engine (CLAUDE.md)

Masternode lists must use immutable data structures (Immer library) for thread safety

Files:

src/masternode/meta.cpp
src/evo/core_write.cpp
src/evo/deterministicmns.cpp

🧠 Learnings (53)

📓 Common learnings

Learnt from: kwvg
PR: dashpay/dash#6543
File: src/wallet/receive.cpp:240-251
Timestamp: 2025-02-06T14:34:30.466Z
Learning: Pull request #6543 is focused on move-only changes and refactoring, specifically backporting from Bitcoin. Behavior changes should be proposed in separate PRs.

Learnt from: kwvg
PR: dashpay/dash#6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

Learnt from: kwvg
PR: dashpay/dash#6761
File: src/chainlock/signing.h:5-6
Timestamp: 2025-07-23T09:30:34.592Z
Learning: Dash Core uses BITCOIN_ prefix for header guards as the standard convention, inherited from Bitcoin Core. Only a few BLS-specific files in src/bls/ use DASH_ prefix. The vast majority of files (385+) use BITCOIN_ prefix.

Learnt from: kwvg
PR: dashpay/dash#6761
File: src/chainlock/signing.cpp:15-250
Timestamp: 2025-07-23T09:28:32.758Z
Learning: In refactoring PRs like #6761, kwvg prefers to defer code formatting fixes to separate follow-up PRs when formatting is not the primary objective, to maintain focus on the structural changes and avoid scope creep.

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/{crc32c,dashbls,gsl,immer,leveldb,minisketch,secp256k1,univalue}/** : Do not make changes under any circumstances to vendored dependencies in src/crc32c, src/dashbls, src/gsl, src/immer, src/leveldb, src/minisketch, src/secp256k1, src/univalue

Learnt from: kwvg
PR: dashpay/dash#6752
File: src/wallet/load.cpp:164-164
Timestamp: 2025-07-17T15:48:29.418Z
Learning: In Dash Core, kwvg prefers using assert() statements to document expected behavior in code paths, especially when the called function also has internal asserts. This is used as a defensive programming pattern rather than requiring conditional error handling.

src/test/blockfilter_tests.cpp (1)

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/{test,wallet/test,qt/test}/**/*.{cpp,h,cc,cxx,hpp} : Unit tests for C++ code should be placed in src/test/, src/wallet/test/, or src/qt/test/ and use Boost::Test or Qt 5 for GUI tests

src/llmq/commitment.h (1)

Learnt from: kwvg
PR: #6665
File: src/evo/providertx.h:82-82
Timestamp: 2025-06-06T11:53:09.094Z
Learning: In ProTx serialization code (SERIALIZE_METHODS), version checks should use hardcoded maximum flags (/is_basic_scheme_active=/true, /is_extended_addr=/true) rather than deployment-based flags. This is because serialization code should be able to deserialize any structurally valid ProTx up to the maximum version the code knows how to handle, regardless of current consensus validity. Validation code, not serialization code, is responsible for checking whether a ProTx version is consensus-valid based on deployment status.

src/test/system_tests.cpp (2)

Learnt from: kwvg
PR: #6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/{test,wallet/test,qt/test}/**/*.{cpp,h,cc,cxx,hpp} : Unit tests for C++ code should be placed in src/test/, src/wallet/test/, or src/qt/test/ and use Boost::Test or Qt 5 for GUI tests

test/lint/lint-files.py (1)

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/{crc32c,dashbls,gsl,immer,leveldb,minisketch,secp256k1,univalue}/** : Do not make changes under any circumstances to vendored dependencies in src/crc32c, src/dashbls, src/gsl, src/immer, src/leveldb, src/minisketch, src/secp256k1, src/univalue

src/univalue/include/univalue_escapes.h (1)

Learnt from: kwvg
PR: #6761
File: src/chainlock/signing.h:5-6
Timestamp: 2025-07-23T09:30:34.592Z
Learning: Dash Core uses BITCOIN_ prefix for header guards as the standard convention, inherited from Bitcoin Core. Only a few BLS-specific files in src/bls/ use DASH_ prefix. The vast majority of files (385+) use BITCOIN_ prefix.

src/core_write.cpp (2)

Learnt from: kwvg
PR: #6665
File: src/evo/providertx.h:82-82
Timestamp: 2025-06-06T11:53:09.094Z
Learning: In ProTx serialization code (SERIALIZE_METHODS), version checks should use hardcoded maximum flags (/is_basic_scheme_active=/true, /is_extended_addr=/true) rather than deployment-based flags. This is because serialization code should be able to deserialize any structurally valid ProTx up to the maximum version the code knows how to handle, regardless of current consensus validity. Validation code, not serialization code, is responsible for checking whether a ProTx version is consensus-valid based on deployment status.

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/evo/specialtx.h : Special transactions use payload extensions defined in src/evo/specialtx.h

test/lint/lint-format-strings.py (2)

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/{crc32c,dashbls,gsl,immer,leveldb,minisketch,secp256k1,univalue}/** : Do not make changes under any circumstances to vendored dependencies in src/crc32c, src/dashbls, src/gsl, src/immer, src/leveldb, src/minisketch, src/secp256k1, src/univalue

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Always run linting before commits using test/lint/all-lint.py

src/test/sighash_tests.cpp (1)

Learnt from: kwvg
PR: #6665
File: src/evo/providertx.h:82-82
Timestamp: 2025-06-06T11:53:09.094Z
Learning: In ProTx serialization code (SERIALIZE_METHODS), version checks should use hardcoded maximum flags (/is_basic_scheme_active=/true, /is_extended_addr=/true) rather than deployment-based flags. This is because serialization code should be able to deserialize any structurally valid ProTx up to the maximum version the code knows how to handle, regardless of current consensus validity. Validation code, not serialization code, is responsible for checking whether a ProTx version is consensus-valid based on deployment status.

ci/test/wrap-wine.sh (2)

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/{test,wallet/test,qt/test}/**/*.{cpp,h,cc,cxx,hpp} : Unit tests for C++ code should be placed in src/test/, src/wallet/test/, or src/qt/test/ and use Boost::Test or Qt 5 for GUI tests

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/{crc32c,dashbls,gsl,immer,leveldb,minisketch,secp256k1,univalue}/** : Do not make changes under any circumstances to vendored dependencies in src/crc32c, src/dashbls, src/gsl, src/immer, src/leveldb, src/minisketch, src/secp256k1, src/univalue

src/wallet/rpc/encrypt.cpp (1)

Learnt from: kwvg
PR: #6529
File: src/wallet/rpcwallet.cpp:3002-3003
Timestamp: 2025-02-14T15:19:17.218Z
Learning: The GetWallet() function calls in src/wallet/rpcwallet.cpp are properly validated with null checks that throw appropriate RPC errors, making additional validation unnecessary.

src/masternode/meta.cpp (2)

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/{masternode,evo}/**/*.{cpp,h,cc,cxx,hpp} : Masternode lists must use immutable data structures (Immer library) for thread safety

Learnt from: kwvg
PR: #6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

src/evo/core_write.cpp (5)

Learnt from: kwvg
PR: #6665
File: src/evo/providertx.h:82-82
Timestamp: 2025-06-06T11:53:09.094Z
Learning: In ProTx serialization code (SERIALIZE_METHODS), version checks should use hardcoded maximum flags (/is_basic_scheme_active=/true, /is_extended_addr=/true) rather than deployment-based flags. This is because serialization code should be able to deserialize any structurally valid ProTx up to the maximum version the code knows how to handle, regardless of current consensus validity. Validation code, not serialization code, is responsible for checking whether a ProTx version is consensus-valid based on deployment status.

Learnt from: kwvg
PR: #6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

Learnt from: kwvg
PR: #6543
File: src/wallet/receive.cpp:240-251
Timestamp: 2025-02-06T14:34:30.466Z
Learning: Pull request #6543 is focused on move-only changes and refactoring, specifically backporting from Bitcoin. Behavior changes should be proposed in separate PRs.

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/{masternode,evo}/**/*.{cpp,h,cc,cxx,hpp} : Masternode lists must use immutable data structures (Immer library) for thread safety

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/evo/specialtx.h : Special transactions use payload extensions defined in src/evo/specialtx.h

src/bitcoin-tx.cpp (3)

Learnt from: kwvg
PR: #6665
File: src/evo/providertx.h:82-82
Timestamp: 2025-06-06T11:53:09.094Z
Learning: In ProTx serialization code (SERIALIZE_METHODS), version checks should use hardcoded maximum flags (/is_basic_scheme_active=/true, /is_extended_addr=/true) rather than deployment-based flags. This is because serialization code should be able to deserialize any structurally valid ProTx up to the maximum version the code knows how to handle, regardless of current consensus validity. Validation code, not serialization code, is responsible for checking whether a ProTx version is consensus-valid based on deployment status.

Learnt from: kwvg
PR: #6530
File: src/validation.cpp:360-362
Timestamp: 2025-01-14T08:37:16.955Z
Learning: The UpdateTransactionsFromBlock() method in txmempool.cpp takes parameters in the order: vHashUpdate, ancestor_size_limit, ancestor_count_limit. The size limit comes before the count limit.

Learnt from: kwvg
PR: #6729
File: src/evo/deterministicmns.cpp:1313-1316
Timestamp: 2025-07-09T15:02:26.899Z
Learning: In Dash's masternode transaction validation, IsVersionChangeValid() is only called by transaction types that update existing masternode entries (like ProUpServTx, ProUpRegTx, ProUpRevTx), not by ProRegTx which creates new entries. This means validation logic in IsVersionChangeValid() only applies to the subset of transaction types that actually call it, not all masternode transaction types.

src/test/fuzz/rpc.cpp (2)

Learnt from: kwvg
PR: #6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

Learnt from: kwvg
PR: #6529
File: src/wallet/rpcwallet.cpp:3002-3003
Timestamp: 2025-02-14T15:19:17.218Z
Learning: The GetWallet() function calls in src/wallet/rpcwallet.cpp are properly validated with null checks that throw appropriate RPC errors, making additional validation unnecessary.

src/univalue/test/test_json.cpp (1)

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/{test,wallet/test,qt/test}/**/*.{cpp,h,cc,cxx,hpp} : Unit tests for C++ code should be placed in src/test/, src/wallet/test/, or src/qt/test/ and use Boost::Test or Qt 5 for GUI tests

src/net_types.cpp (1)

Learnt from: kwvg
PR: #6629
File: src/evo/deterministicmns.cpp:473-485
Timestamp: 2025-05-10T00:54:15.597Z
Learning: In the current implementation of NetInfoEntry, only CService is a valid type and std::monostate represents an invalid state. Entries that don't provide a valid CService through GetAddrPort() should be rejected with an exception, not silently skipped.

src/wallet/rpc/spend.cpp (2)

Learnt from: kwvg
PR: #6529
File: src/wallet/rpcwallet.cpp:3002-3003
Timestamp: 2025-02-14T15:19:17.218Z
Learning: The GetWallet() function calls in src/wallet/rpcwallet.cpp are properly validated with null checks that throw appropriate RPC errors, making additional validation unnecessary.

Learnt from: kwvg
PR: #6543
File: src/wallet/receive.cpp:240-251
Timestamp: 2025-02-06T14:34:30.466Z
Learning: Pull request #6543 is focused on move-only changes and refactoring, specifically backporting from Bitcoin. Behavior changes should be proposed in separate PRs.

src/test/key_io_tests.cpp (2)

Learnt from: kwvg
PR: #6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/{test,wallet/test,qt/test}/**/*.{cpp,h,cc,cxx,hpp} : Unit tests for C++ code should be placed in src/test/, src/wallet/test/, or src/qt/test/ and use Boost::Test or Qt 5 for GUI tests

test/lint/lint-spelling.py (1)

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/{crc32c,dashbls,gsl,immer,leveldb,minisketch,secp256k1,univalue}/** : Do not make changes under any circumstances to vendored dependencies in src/crc32c, src/dashbls, src/gsl, src/immer, src/leveldb, src/minisketch, src/secp256k1, src/univalue

src/rpc/rawtransaction_util.cpp (4)

Learnt from: kwvg
PR: #6529
File: src/wallet/rpcwallet.cpp:3002-3003
Timestamp: 2025-02-14T15:19:17.218Z
Learning: The GetWallet() function calls in src/wallet/rpcwallet.cpp are properly validated with null checks that throw appropriate RPC errors, making additional validation unnecessary.

Learnt from: kwvg
PR: #6665
File: src/evo/providertx.h:82-82
Timestamp: 2025-06-06T11:53:09.094Z
Learning: In ProTx serialization code (SERIALIZE_METHODS), version checks should use hardcoded maximum flags (/is_basic_scheme_active=/true, /is_extended_addr=/true) rather than deployment-based flags. This is because serialization code should be able to deserialize any structurally valid ProTx up to the maximum version the code knows how to handle, regardless of current consensus validity. Validation code, not serialization code, is responsible for checking whether a ProTx version is consensus-valid based on deployment status.

Learnt from: kwvg
PR: #6543
File: src/wallet/receive.cpp:240-251
Timestamp: 2025-02-06T14:34:30.466Z
Learning: Pull request #6543 is focused on move-only changes and refactoring, specifically backporting from Bitcoin. Behavior changes should be proposed in separate PRs.

Learnt from: kwvg
PR: #6530
File: src/validation.cpp:360-362
Timestamp: 2025-01-14T08:37:16.955Z
Learning: The UpdateTransactionsFromBlock() method in txmempool.cpp takes parameters in the order: vHashUpdate, ancestor_size_limit, ancestor_count_limit. The size limit comes before the count limit.

src/rpc/masternode.cpp (3)

Learnt from: kwvg
PR: #6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/{masternode,evo}/**/*.{cpp,h,cc,cxx,hpp} : Masternode lists must use immutable data structures (Immer library) for thread safety

Learnt from: kwvg
PR: #6729
File: src/evo/deterministicmns.cpp:1313-1316
Timestamp: 2025-07-09T15:02:26.899Z
Learning: In Dash's masternode transaction validation, IsVersionChangeValid() is only called by transaction types that update existing masternode entries (like ProUpServTx, ProUpRegTx, ProUpRevTx), not by ProRegTx which creates new entries. This means validation logic in IsVersionChangeValid() only applies to the subset of transaction types that actually call it, not all masternode transaction types.

src/univalue/test/unitester.cpp (2)

Learnt from: kwvg
PR: #6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/{test,wallet/test,qt/test}/**/*.{cpp,h,cc,cxx,hpp} : Unit tests for C++ code should be placed in src/test/, src/wallet/test/, or src/qt/test/ and use Boost::Test or Qt 5 for GUI tests

src/Makefile.test.include (2)

Learnt from: kwvg
PR: #6516
File: depends/patches/gmp/include_ldflags_in_configure.patch:557-621
Timestamp: 2025-01-06T09:51:03.167Z
Learning: The GMP_GCC_ARM_UMODSI macro checks only the compiler version, and GMP_GCC_MIPS_O32 relies on the -mabi=32 flag. Therefore, $LDFLAGS is irrelevant to these tests.

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/{test,wallet/test,qt/test}/**/*.{cpp,h,cc,cxx,hpp} : Unit tests for C++ code should be placed in src/test/, src/wallet/test/, or src/qt/test/ and use Boost::Test or Qt 5 for GUI tests

src/rpc/util.cpp (3)

Learnt from: kwvg
PR: #6529
File: src/wallet/rpcwallet.cpp:3002-3003
Timestamp: 2025-02-14T15:19:17.218Z
Learning: The GetWallet() function calls in src/wallet/rpcwallet.cpp are properly validated with null checks that throw appropriate RPC errors, making additional validation unnecessary.

Learnt from: kwvg
PR: #6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

Learnt from: kwvg
PR: #6665
File: src/evo/providertx.h:82-82
Timestamp: 2025-06-06T11:53:09.094Z
Learning: In ProTx serialization code (SERIALIZE_METHODS), version checks should use hardcoded maximum flags (/is_basic_scheme_active=/true, /is_extended_addr=/true) rather than deployment-based flags. This is because serialization code should be able to deserialize any structurally valid ProTx up to the maximum version the code knows how to handle, regardless of current consensus validity. Validation code, not serialization code, is responsible for checking whether a ProTx version is consensus-valid based on deployment status.

src/wallet/rpc/addresses.cpp (3)

Learnt from: kwvg
PR: #6529
File: src/wallet/rpcwallet.cpp:3002-3003
Timestamp: 2025-02-14T15:19:17.218Z
Learning: The GetWallet() function calls in src/wallet/rpcwallet.cpp are properly validated with null checks that throw appropriate RPC errors, making additional validation unnecessary.

Learnt from: kwvg
PR: #6543
File: src/wallet/receive.cpp:240-251
Timestamp: 2025-02-06T14:34:30.466Z
Learning: Pull request #6543 is focused on move-only changes and refactoring, specifically backporting from Bitcoin. Behavior changes should be proposed in separate PRs.

Learnt from: kwvg
PR: #6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

src/httprpc.cpp (2)

Learnt from: kwvg
PR: #6529
File: src/wallet/rpcwallet.cpp:3002-3003
Timestamp: 2025-02-14T15:19:17.218Z
Learning: The GetWallet() function calls in src/wallet/rpcwallet.cpp are properly validated with null checks that throw appropriate RPC errors, making additional validation unnecessary.

Learnt from: kwvg
PR: #6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

configure.ac (2)

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/**/*.{cpp,h,cc,cxx,hpp} : Dash Core C++ codebase must be written in C++20 and require at least Clang 16 or GCC 11.1

Learnt from: kwvg
PR: #6516
File: depends/patches/gmp/include_ldflags_in_configure.patch:557-621
Timestamp: 2025-01-06T09:51:03.167Z
Learning: The GMP_GCC_ARM_UMODSI macro checks only the compiler version, and GMP_GCC_MIPS_O32 relies on the -mabi=32 flag. Therefore, $LDFLAGS is irrelevant to these tests.

src/node/interfaces.cpp (2)

Learnt from: kwvg
PR: #6529
File: src/wallet/rpcwallet.cpp:3002-3003
Timestamp: 2025-02-14T15:19:17.218Z
Learning: The GetWallet() function calls in src/wallet/rpcwallet.cpp are properly validated with null checks that throw appropriate RPC errors, making additional validation unnecessary.

Learnt from: kwvg
PR: #6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

src/rpc/mempool.cpp (4)

Learnt from: kwvg
PR: #6543
File: src/wallet/receive.cpp:240-251
Timestamp: 2025-02-06T14:34:30.466Z
Learning: Pull request #6543 is focused on move-only changes and refactoring, specifically backporting from Bitcoin. Behavior changes should be proposed in separate PRs.

Learnt from: kwvg
PR: #6529
File: src/wallet/rpcwallet.cpp:3002-3003
Timestamp: 2025-02-14T15:19:17.218Z
Learning: The GetWallet() function calls in src/wallet/rpcwallet.cpp are properly validated with null checks that throw appropriate RPC errors, making additional validation unnecessary.

Learnt from: kwvg
PR: #6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

Learnt from: kwvg
PR: #6665
File: src/evo/providertx.h:82-82
Timestamp: 2025-06-06T11:53:09.094Z
Learning: In ProTx serialization code (SERIALIZE_METHODS), version checks should use hardcoded maximum flags (/is_basic_scheme_active=/true, /is_extended_addr=/true) rather than deployment-based flags. This is because serialization code should be able to deserialize any structurally valid ProTx up to the maximum version the code knows how to handle, regardless of current consensus validity. Validation code, not serialization code, is responsible for checking whether a ProTx version is consensus-valid based on deployment status.

test/lint/lint-shell-locale.py (1)

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/{crc32c,dashbls,gsl,immer,leveldb,minisketch,secp256k1,univalue}/** : Do not make changes under any circumstances to vendored dependencies in src/crc32c, src/dashbls, src/gsl, src/immer, src/leveldb, src/minisketch, src/secp256k1, src/univalue

src/qt/rpcconsole.cpp (1)

Learnt from: kwvg
PR: #6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

src/wallet/rpc/coins.cpp (3)

Learnt from: kwvg
PR: #6529
File: src/wallet/rpcwallet.cpp:3002-3003
Timestamp: 2025-02-14T15:19:17.218Z
Learning: The GetWallet() function calls in src/wallet/rpcwallet.cpp are properly validated with null checks that throw appropriate RPC errors, making additional validation unnecessary.

Learnt from: kwvg
PR: #6543
File: src/wallet/receive.cpp:240-251
Timestamp: 2025-02-06T14:34:30.466Z
Learning: Pull request #6543 is focused on move-only changes and refactoring, specifically backporting from Bitcoin. Behavior changes should be proposed in separate PRs.

Learnt from: kwvg
PR: #6530
File: src/validation.cpp:360-362
Timestamp: 2025-01-14T08:37:16.955Z
Learning: The UpdateTransactionsFromBlock() method in txmempool.cpp takes parameters in the order: vHashUpdate, ancestor_size_limit, ancestor_count_limit. The size limit comes before the count limit.

src/rpc/blockchain.cpp (6)

Learnt from: kwvg
PR: #6543
File: src/wallet/receive.cpp:240-251
Timestamp: 2025-02-06T14:34:30.466Z
Learning: Pull request #6543 is focused on move-only changes and refactoring, specifically backporting from Bitcoin. Behavior changes should be proposed in separate PRs.

Learnt from: kwvg
PR: #6529
File: src/wallet/rpcwallet.cpp:3002-3003
Timestamp: 2025-02-14T15:19:17.218Z
Learning: The GetWallet() function calls in src/wallet/rpcwallet.cpp are properly validated with null checks that throw appropriate RPC errors, making additional validation unnecessary.

Learnt from: kwvg
PR: #6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

Learnt from: kwvg
PR: #6530
File: src/validation.cpp:360-362
Timestamp: 2025-01-14T08:37:16.955Z
Learning: The UpdateTransactionsFromBlock() method in txmempool.cpp takes parameters in the order: vHashUpdate, ancestor_size_limit, ancestor_count_limit. The size limit comes before the count limit.

Learnt from: kwvg
PR: #6665
File: src/evo/providertx.h:82-82
Timestamp: 2025-06-06T11:53:09.094Z
Learning: In ProTx serialization code (SERIALIZE_METHODS), version checks should use hardcoded maximum flags (/is_basic_scheme_active=/true, /is_extended_addr=/true) rather than deployment-based flags. This is because serialization code should be able to deserialize any structurally valid ProTx up to the maximum version the code knows how to handle, regardless of current consensus validity. Validation code, not serialization code, is responsible for checking whether a ProTx version is consensus-valid based on deployment status.

Learnt from: knst
PR: #6658
File: src/evo/creditpool.cpp:177-185
Timestamp: 2025-05-05T12:45:44.781Z
Learning: The GetAncestor() function in CBlockIndex safely handles negative heights by returning nullptr rather than asserting, making it safe to call with potentially negative values.

src/wallet/rpc/wallet.cpp (4)

Learnt from: kwvg
PR: #6529
File: src/wallet/rpcwallet.cpp:3002-3003
Timestamp: 2025-02-14T15:19:17.218Z
Learning: The GetWallet() function calls in src/wallet/rpcwallet.cpp are properly validated with null checks that throw appropriate RPC errors, making additional validation unnecessary.

Learnt from: kwvg
PR: #6543
File: src/wallet/receive.cpp:240-251
Timestamp: 2025-02-06T14:34:30.466Z
Learning: Pull request #6543 is focused on move-only changes and refactoring, specifically backporting from Bitcoin. Behavior changes should be proposed in separate PRs.

Learnt from: kwvg
PR: #6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

Learnt from: kwvg
PR: #6665
File: src/evo/providertx.h:82-82
Timestamp: 2025-06-06T11:53:09.094Z
Learning: In ProTx serialization code (SERIALIZE_METHODS), version checks should use hardcoded maximum flags (/is_basic_scheme_active=/true, /is_extended_addr=/true) rather than deployment-based flags. This is because serialization code should be able to deserialize any structurally valid ProTx up to the maximum version the code knows how to handle, regardless of current consensus validity. Validation code, not serialization code, is responsible for checking whether a ProTx version is consensus-valid based on deployment status.

src/rpc/governance.cpp (3)

Learnt from: kwvg
PR: #6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

Learnt from: kwvg
PR: #6529
File: src/wallet/rpcwallet.cpp:3002-3003
Timestamp: 2025-02-14T15:19:17.218Z
Learning: The GetWallet() function calls in src/wallet/rpcwallet.cpp are properly validated with null checks that throw appropriate RPC errors, making additional validation unnecessary.

Learnt from: knst
PR: #6658
File: src/evo/creditpool.cpp:177-185
Timestamp: 2025-05-05T12:45:44.781Z
Learning: The GetAncestor() function in CBlockIndex safely handles negative heights by returning nullptr rather than asserting, making it safe to call with potentially negative values.

src/rpc/mining.cpp (5)

Learnt from: kwvg
PR: #6529
File: src/wallet/rpcwallet.cpp:3002-3003
Timestamp: 2025-02-14T15:19:17.218Z
Learning: The GetWallet() function calls in src/wallet/rpcwallet.cpp are properly validated with null checks that throw appropriate RPC errors, making additional validation unnecessary.

Learnt from: kwvg
PR: #6543
File: src/wallet/receive.cpp:240-251
Timestamp: 2025-02-06T14:34:30.466Z
Learning: Pull request #6543 is focused on move-only changes and refactoring, specifically backporting from Bitcoin. Behavior changes should be proposed in separate PRs.

Learnt from: kwvg
PR: #6665
File: src/evo/providertx.h:82-82
Timestamp: 2025-06-06T11:53:09.094Z
Learning: In ProTx serialization code (SERIALIZE_METHODS), version checks should use hardcoded maximum flags (/is_basic_scheme_active=/true, /is_extended_addr=/true) rather than deployment-based flags. This is because serialization code should be able to deserialize any structurally valid ProTx up to the maximum version the code knows how to handle, regardless of current consensus validity. Validation code, not serialization code, is responsible for checking whether a ProTx version is consensus-valid based on deployment status.

Learnt from: kwvg
PR: #6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

Learnt from: kwvg
PR: #6530
File: src/validation.cpp:360-362
Timestamp: 2025-01-14T08:37:16.955Z
Learning: The UpdateTransactionsFromBlock() method in txmempool.cpp takes parameters in the order: vHashUpdate, ancestor_size_limit, ancestor_count_limit. The size limit comes before the count limit.

src/test/rpc_tests.cpp (6)

Learnt from: kwvg
PR: #6529
File: src/wallet/rpcwallet.cpp:3002-3003
Timestamp: 2025-02-14T15:19:17.218Z
Learning: The GetWallet() function calls in src/wallet/rpcwallet.cpp are properly validated with null checks that throw appropriate RPC errors, making additional validation unnecessary.

Learnt from: kwvg
PR: #6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/{test,wallet/test,qt/test}/**/*.{cpp,h,cc,cxx,hpp} : Unit tests for C++ code should be placed in src/test/, src/wallet/test/, or src/qt/test/ and use Boost::Test or Qt 5 for GUI tests

Learnt from: kwvg
PR: #6665
File: src/evo/providertx.h:82-82
Timestamp: 2025-06-06T11:53:09.094Z
Learning: In ProTx serialization code (SERIALIZE_METHODS), version checks should use hardcoded maximum flags (/is_basic_scheme_active=/true, /is_extended_addr=/true) rather than deployment-based flags. This is because serialization code should be able to deserialize any structurally valid ProTx up to the maximum version the code knows how to handle, regardless of current consensus validity. Validation code, not serialization code, is responsible for checking whether a ProTx version is consensus-valid based on deployment status.

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/evo/specialtx.h : Special transactions use payload extensions defined in src/evo/specialtx.h

Learnt from: kwvg
PR: #6629
File: src/evo/deterministicmns.cpp:473-485
Timestamp: 2025-05-10T00:54:15.597Z
Learning: In the current implementation of NetInfoEntry, only CService is a valid type and std::monostate represents an invalid state. Entries that don't provide a valid CService through GetAddrPort() should be rejected with an exception, not silently skipped.

src/univalue/sources.mk (1)

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/{test,wallet/test,qt/test}/**/*.{cpp,h,cc,cxx,hpp} : Unit tests for C++ code should be placed in src/test/, src/wallet/test/, or src/qt/test/ and use Boost::Test or Qt 5 for GUI tests

src/test/transaction_tests.cpp (5)

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/{test,wallet/test,qt/test}/**/*.{cpp,h,cc,cxx,hpp} : Unit tests for C++ code should be placed in src/test/, src/wallet/test/, or src/qt/test/ and use Boost::Test or Qt 5 for GUI tests

Learnt from: kwvg
PR: #6529
File: src/wallet/rpcwallet.cpp:3002-3003
Timestamp: 2025-02-14T15:19:17.218Z
Learning: The GetWallet() function calls in src/wallet/rpcwallet.cpp are properly validated with null checks that throw appropriate RPC errors, making additional validation unnecessary.

Learnt from: kwvg
PR: #6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

Learnt from: kwvg
PR: #6665
File: src/evo/providertx.h:82-82
Timestamp: 2025-06-06T11:53:09.094Z
Learning: In ProTx serialization code (SERIALIZE_METHODS), version checks should use hardcoded maximum flags (/is_basic_scheme_active=/true, /is_extended_addr=/true) rather than deployment-based flags. This is because serialization code should be able to deserialize any structurally valid ProTx up to the maximum version the code knows how to handle, regardless of current consensus validity. Validation code, not serialization code, is responsible for checking whether a ProTx version is consensus-valid based on deployment status.

Learnt from: kwvg
PR: #6530
File: src/validation.cpp:360-362
Timestamp: 2025-01-14T08:37:16.955Z
Learning: The UpdateTransactionsFromBlock() method in txmempool.cpp takes parameters in the order: vHashUpdate, ancestor_size_limit, ancestor_count_limit. The size limit comes before the count limit.

src/rpc/quorums.cpp (5)

Learnt from: kwvg
PR: #6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

Learnt from: kwvg
PR: #6529
File: src/wallet/rpcwallet.cpp:3002-3003
Timestamp: 2025-02-14T15:19:17.218Z
Learning: The GetWallet() function calls in src/wallet/rpcwallet.cpp are properly validated with null checks that throw appropriate RPC errors, making additional validation unnecessary.

Learnt from: kwvg
PR: #6543
File: src/wallet/receive.cpp:240-251
Timestamp: 2025-02-06T14:34:30.466Z
Learning: Pull request #6543 is focused on move-only changes and refactoring, specifically backporting from Bitcoin. Behavior changes should be proposed in separate PRs.

Learnt from: knst
PR: #6658
File: src/evo/creditpool.cpp:177-185
Timestamp: 2025-05-05T12:45:44.781Z
Learning: The GetAncestor() function in CBlockIndex safely handles negative heights by returning nullptr rather than asserting, making it safe to call with potentially negative values.

Learnt from: kwvg
PR: #6530
File: src/validation.cpp:360-362
Timestamp: 2025-01-14T08:37:16.955Z
Learning: The UpdateTransactionsFromBlock() method in txmempool.cpp takes parameters in the order: vHashUpdate, ancestor_size_limit, ancestor_count_limit. The size limit comes before the count limit.

src/evo/deterministicmns.cpp (3)

Learnt from: knst
PR: #6511
File: src/evo/deterministicmns.cpp:1369-1373
Timestamp: 2025-01-07T18:50:44.838Z
Learning: The functions MigrateDBIfNeeded and MigrateDBIfNeeded2 in src/evo/deterministicmns.cpp are temporary and will be removed in a future version. Refactoring suggestions for these functions should be avoided.

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/{masternode,evo}/**/*.{cpp,h,cc,cxx,hpp} : Masternode lists must use immutable data structures (Immer library) for thread safety

Learnt from: kwvg
PR: #6665
File: src/evo/providertx.h:82-82
Timestamp: 2025-06-06T11:53:09.094Z
Learning: In ProTx serialization code (SERIALIZE_METHODS), version checks should use hardcoded maximum flags (/is_basic_scheme_active=/true, /is_extended_addr=/true) rather than deployment-based flags. This is because serialization code should be able to deserialize any structurally valid ProTx up to the maximum version the code knows how to handle, regardless of current consensus validity. Validation code, not serialization code, is responsible for checking whether a ProTx version is consensus-valid based on deployment status.

src/rpc/net.cpp (2)

Learnt from: kwvg
PR: #6529
File: src/wallet/rpcwallet.cpp:3002-3003
Timestamp: 2025-02-14T15:19:17.218Z
Learning: The GetWallet() function calls in src/wallet/rpcwallet.cpp are properly validated with null checks that throw appropriate RPC errors, making additional validation unnecessary.

Learnt from: kwvg
PR: #6629
File: src/evo/deterministicmns.cpp:473-485
Timestamp: 2025-05-10T00:54:15.597Z
Learning: In the current implementation of NetInfoEntry, only CService is a valid type and std::monostate represents an invalid state. Entries that don't provide a valid CService through GetAddrPort() should be rejected with an exception, not silently skipped.

src/bitcoin-cli.cpp (6)

Learnt from: kwvg
PR: #6529
File: src/wallet/rpcwallet.cpp:3002-3003
Timestamp: 2025-02-14T15:19:17.218Z
Learning: The GetWallet() function calls in src/wallet/rpcwallet.cpp are properly validated with null checks that throw appropriate RPC errors, making additional validation unnecessary.

Learnt from: kwvg
PR: #6665
File: src/evo/providertx.h:82-82
Timestamp: 2025-06-06T11:53:09.094Z
Learning: In ProTx serialization code (SERIALIZE_METHODS), version checks should use hardcoded maximum flags (/is_basic_scheme_active=/true, /is_extended_addr=/true) rather than deployment-based flags. This is because serialization code should be able to deserialize any structurally valid ProTx up to the maximum version the code knows how to handle, regardless of current consensus validity. Validation code, not serialization code, is responsible for checking whether a ProTx version is consensus-valid based on deployment status.

Learnt from: kwvg
PR: #6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

Learnt from: kwvg
PR: #6543
File: src/wallet/receive.cpp:240-251
Timestamp: 2025-02-06T14:34:30.466Z
Learning: Pull request #6543 is focused on move-only changes and refactoring, specifically backporting from Bitcoin. Behavior changes should be proposed in separate PRs.

Learnt from: kwvg
PR: #6629
File: src/evo/deterministicmns.cpp:473-485
Timestamp: 2025-05-10T00:54:15.597Z
Learning: In the current implementation of NetInfoEntry, only CService is a valid type and std::monostate represents an invalid state. Entries that don't provide a valid CService through GetAddrPort() should be rejected with an exception, not silently skipped.

Learnt from: kwvg
PR: #6530
File: src/validation.cpp:4514-4516
Timestamp: 2025-01-14T08:40:00.994Z
Learning: In Dash Core, error() is used (instead of state.Invalid()) to report critical failures that require immediate user intervention, particularly for database/disk errors and data corruption scenarios. This is an established pattern seen in validation.cpp.

src/univalue/include/univalue_utffilter.h (1)

Learnt from: kwvg
PR: #6761
File: src/chainlock/signing.h:5-6
Timestamp: 2025-07-23T09:30:34.592Z
Learning: Dash Core uses BITCOIN_ prefix for header guards as the standard convention, inherited from Bitcoin Core. Only a few BLS-specific files in src/bls/ use DASH_ prefix. The vast majority of files (385+) use BITCOIN_ prefix.

src/wallet/rpc/transactions.cpp (3)

Learnt from: kwvg
PR: #6529
File: src/wallet/rpcwallet.cpp:3002-3003
Timestamp: 2025-02-14T15:19:17.218Z
Learning: The GetWallet() function calls in src/wallet/rpcwallet.cpp are properly validated with null checks that throw appropriate RPC errors, making additional validation unnecessary.

Learnt from: kwvg
PR: #6530
File: src/validation.cpp:360-362
Timestamp: 2025-01-14T08:37:16.955Z
Learning: The UpdateTransactionsFromBlock() method in txmempool.cpp takes parameters in the order: vHashUpdate, ancestor_size_limit, ancestor_count_limit. The size limit comes before the count limit.

Learnt from: knst
PR: #6658
File: src/evo/creditpool.cpp:177-185
Timestamp: 2025-05-05T12:45:44.781Z
Learning: The GetAncestor() function in CBlockIndex safely handles negative heights by returning nullptr rather than asserting, making it safe to call with potentially negative values.

src/governance/governance.cpp (2)

Learnt from: kwvg
PR: #6543
File: src/wallet/receive.cpp:240-251
Timestamp: 2025-02-06T14:34:30.466Z
Learning: Pull request #6543 is focused on move-only changes and refactoring, specifically backporting from Bitcoin. Behavior changes should be proposed in separate PRs.

Learnt from: kwvg
PR: #6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

src/rpc/node.cpp (5)

Learnt from: kwvg
PR: #6543
File: src/wallet/receive.cpp:240-251
Timestamp: 2025-02-06T14:34:30.466Z
Learning: Pull request #6543 is focused on move-only changes and refactoring, specifically backporting from Bitcoin. Behavior changes should be proposed in separate PRs.

Learnt from: kwvg
PR: #6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

Learnt from: kwvg
PR: #6529
File: src/wallet/rpcwallet.cpp:3002-3003
Timestamp: 2025-02-14T15:19:17.218Z
Learning: The GetWallet() function calls in src/wallet/rpcwallet.cpp are properly validated with null checks that throw appropriate RPC errors, making additional validation unnecessary.

Learnt from: kwvg
PR: #6530
File: src/validation.cpp:360-362
Timestamp: 2025-01-14T08:37:16.955Z
Learning: The UpdateTransactionsFromBlock() method in txmempool.cpp takes parameters in the order: vHashUpdate, ancestor_size_limit, ancestor_count_limit. The size limit comes before the count limit.

Learnt from: kwvg
PR: #6665
File: src/evo/deterministicmns.cpp:1284-1287
Timestamp: 2025-06-16T17:59:55.669Z
Learning: In Dash masternode ProRegTx validation, platform ports (platformHTTPPort and platformP2PPort) are mandatory and must be non-zero, while netInfo (ipAndPort) is optional. This means that even if an empty netInfo returns 0 from GetPrimary().GetPort(), it won't cause false positives in port duplication checks since platform ports cannot be 0.

src/rpc/rawtransaction.cpp (3)

Learnt from: kwvg
PR: #6529
File: src/wallet/rpcwallet.cpp:3002-3003
Timestamp: 2025-02-14T15:19:17.218Z
Learning: The GetWallet() function calls in src/wallet/rpcwallet.cpp are properly validated with null checks that throw appropriate RPC errors, making additional validation unnecessary.

Learnt from: kwvg
PR: #6665
File: src/evo/providertx.h:82-82
Timestamp: 2025-06-06T11:53:09.094Z
Learning: In ProTx serialization code (SERIALIZE_METHODS), version checks should use hardcoded maximum flags (/is_basic_scheme_active=/true, /is_extended_addr=/true) rather than deployment-based flags. This is because serialization code should be able to deserialize any structurally valid ProTx up to the maximum version the code knows how to handle, regardless of current consensus validity. Validation code, not serialization code, is responsible for checking whether a ProTx version is consensus-valid based on deployment status.

Learnt from: knst
PR: #6658
File: src/evo/creditpool.cpp:177-185
Timestamp: 2025-05-05T12:45:44.781Z
Learning: The GetAncestor() function in CBlockIndex safely handles negative heights by returning nullptr rather than asserting, making it safe to call with potentially negative values.

src/rpc/client.cpp (1)

Learnt from: kwvg
PR: #6529
File: src/wallet/rpcwallet.cpp:3002-3003
Timestamp: 2025-02-14T15:19:17.218Z
Learning: The GetWallet() function calls in src/wallet/rpcwallet.cpp are properly validated with null checks that throw appropriate RPC errors, making additional validation unnecessary.

src/wallet/test/wallet_tests.cpp (3)

Learnt from: kwvg
PR: #6529
File: src/wallet/rpcwallet.cpp:3002-3003
Timestamp: 2025-02-14T15:19:17.218Z
Learning: The GetWallet() function calls in src/wallet/rpcwallet.cpp are properly validated with null checks that throw appropriate RPC errors, making additional validation unnecessary.

Learnt from: kwvg
PR: #6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/{test,wallet/test,qt/test}/**/*.{cpp,h,cc,cxx,hpp} : Unit tests for C++ code should be placed in src/test/, src/wallet/test/, or src/qt/test/ and use Boost::Test or Qt 5 for GUI tests

src/wallet/rpc/backup.cpp (1)

Learnt from: kwvg
PR: #6529
File: src/wallet/rpcwallet.cpp:3002-3003
Timestamp: 2025-02-14T15:19:17.218Z
Learning: The GetWallet() function calls in src/wallet/rpcwallet.cpp are properly validated with null checks that throw appropriate RPC errors, making additional validation unnecessary.

src/univalue/test/object.cpp (2)

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/{test,wallet/test,qt/test}/**/*.{cpp,h,cc,cxx,hpp} : Unit tests for C++ code should be placed in src/test/, src/wallet/test/, or src/qt/test/ and use Boost::Test or Qt 5 for GUI tests

Learnt from: kwvg
PR: #6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

🧬 Code Graph Analysis (4)

src/wallet/rpc/addresses.cpp (2)

src/qt/rpcconsole.cpp (2)

request (422-476)

request (422-422)

src/rpc/request.cpp (3)

request (31-31)

JSONRPCError (56-62)

JSONRPCError (56-56)

src/wallet/rpc/wallet.cpp (2)

src/node/interfaces.cpp (6)

nRounds (262-265)

nRounds (262-262)

nAmount (286-289)

nAmount (286-286)

nAmount (302-305)

nAmount (302-302)

src/core_write.cpp (2)

ValueFromAmount (36-47)

ValueFromAmount (36-36)

src/rpc/client.h (1)

src/rpc/client.cpp (2)

ParseNonRFCJSONValue (293-298)

ParseNonRFCJSONValue (293-293)

src/wallet/test/wallet_tests.cpp (1)

src/wallet/rpc/addresses.cpp (5)

getaddressinfo (420-561)

getaddressinfo (420-420)

labels (551-551)

pubkeys (369-369)

addresses (370-370)

🪛 GitHub Actions: Clang Diff Format Check

src/rpc/governance.cpp

[error] 1028-1055: Clang format differences found. The code formatting does not match the expected style. Please run clang-format to fix formatting issues.

🪛 Gitleaks (8.27.2)

src/test/rpc_tests.cpp

590-590: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.

(generic-api-key)

💤 Files with no reviewable changes (23)

src/univalue/test/.gitignore
test/lint/README.md
contrib/devtools/copyright_header.py
src/univalue/test/no_nul.cpp
ci/lint/06_script.sh
src/univalue/TODO
test/lint/lint-includes.py
.gitignore
src/univalue/autogen.sh
Makefile.am
test/lint/lint-include-guards.py
src/univalue/pc/libunivalue.pc.in
src/univalue/pc/libunivalue-uninstalled.pc.in
src/univalue/.cirrus.yml
src/univalue/COPYING
src/univalue/README.md
doc/developer-notes.md
src/univalue/build-aux/m4/.gitignore
src/univalue/Makefile.am
test/lint/lint-locale-dependence.py
src/univalue/configure.ac
test/lint/lint-whitespace.py
src/univalue/build-aux/m4/ax_cxx_compile_stdcxx.m4

🧰 Additional context used

📓 Path-based instructions (5)

src/**/*.{cpp,h,cc,cxx,hpp}

📄 CodeRabbit Inference Engine (CLAUDE.md)

src/**/*.{cpp,h,cc,cxx,hpp}: Dash Core C++ codebase must be written in C++20 and require at least Clang 16 or GCC 11.1
Dash uses unordered_lru_cache for efficient caching with LRU eviction

Files:

src/test/blockfilter_tests.cpp
src/llmq/commitment.h
src/test/system_tests.cpp
src/univalue/include/univalue_escapes.h
src/core_write.cpp
src/test/sighash_tests.cpp
src/wallet/rpc/encrypt.cpp
src/masternode/meta.cpp
src/evo/core_write.cpp
src/univalue/lib/univalue_read.cpp
src/bitcoin-tx.cpp
src/test/fuzz/rpc.cpp
src/governance/object.cpp
src/governance/validators.cpp
src/univalue/test/test_json.cpp
src/net_types.cpp
src/wallet/rpc/spend.cpp
src/test/key_io_tests.cpp
src/governance/classes.cpp
src/rpc/rawtransaction_util.cpp
src/util/system.cpp
src/rpc/server.cpp
src/rpc/masternode.cpp
src/univalue/test/unitester.cpp
src/rpc/request.cpp
src/util/settings.h
src/rpc/util.cpp
src/wallet/rpc/addresses.cpp
src/httprpc.cpp
src/node/interfaces.cpp
src/rpc/mempool.cpp
src/qt/governancelist.cpp
src/qt/rpcconsole.cpp
src/univalue/lib/univalue_write.cpp
src/rpc/output_script.cpp
src/wallet/rpc/coins.cpp
src/rpc/blockchain.cpp
src/wallet/rpc/wallet.cpp
src/rpc/governance.cpp
src/rpc/mining.cpp
src/rpc/client.h
src/univalue/lib/univalue_get.cpp
src/test/rpc_tests.cpp
src/test/transaction_tests.cpp
src/rpc/quorums.cpp
src/evo/deterministicmns.cpp
src/rpc/net.cpp
src/bitcoin-cli.cpp
src/univalue/include/univalue_utffilter.h
src/wallet/rpc/transactions.cpp
src/coinjoin/options.cpp
src/governance/governance.cpp
src/rpc/node.cpp
src/rpc/rawtransaction.cpp
src/rpc/client.cpp
src/univalue/lib/univalue.cpp
src/wallet/test/wallet_tests.cpp
src/wallet/rpc/backup.cpp
src/univalue/include/univalue.h
src/univalue/test/object.cpp

src/{test,wallet/test,qt/test}/**/*.{cpp,h,cc,cxx,hpp}

📄 CodeRabbit Inference Engine (CLAUDE.md)

Unit tests for C++ code should be placed in src/test/, src/wallet/test/, or src/qt/test/ and use Boost::Test or Qt 5 for GUI tests

Files:

src/test/blockfilter_tests.cpp
src/test/system_tests.cpp
src/test/sighash_tests.cpp
src/test/fuzz/rpc.cpp
src/test/key_io_tests.cpp
src/test/rpc_tests.cpp
src/test/transaction_tests.cpp
src/wallet/test/wallet_tests.cpp

src/{crc32c,dashbls,gsl,immer,leveldb,minisketch,secp256k1,univalue}/**

📄 CodeRabbit Inference Engine (CLAUDE.md)

Do not make changes under any circumstances to vendored dependencies in src/crc32c, src/dashbls, src/gsl, src/immer, src/leveldb, src/minisketch, src/secp256k1, src/univalue

Files:

src/univalue/include/univalue_escapes.h
src/univalue/lib/univalue_read.cpp
src/univalue/test/test_json.cpp
src/univalue/test/unitester.cpp
src/univalue/lib/univalue_write.cpp
src/univalue/lib/univalue_get.cpp
src/univalue/sources.mk
src/univalue/include/univalue_utffilter.h
src/univalue/lib/univalue.cpp
src/univalue/include/univalue.h
src/univalue/test/object.cpp

ci/**

📄 CodeRabbit Inference Engine (CLAUDE.md)

Unless specifically prompted, avoid making changes to the ci directory (continuous integration)

Files:

ci/test/wrap-wine.sh

src/{masternode,evo}/**/*.{cpp,h,cc,cxx,hpp}

📄 CodeRabbit Inference Engine (CLAUDE.md)

Masternode lists must use immutable data structures (Immer library) for thread safety

Files:

src/masternode/meta.cpp
src/evo/core_write.cpp
src/evo/deterministicmns.cpp

🧠 Learnings (53)

📓 Common learnings

Learnt from: kwvg
PR: dashpay/dash#6543
File: src/wallet/receive.cpp:240-251
Timestamp: 2025-02-06T14:34:30.466Z
Learning: Pull request #6543 is focused on move-only changes and refactoring, specifically backporting from Bitcoin. Behavior changes should be proposed in separate PRs.

Learnt from: kwvg
PR: dashpay/dash#6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

Learnt from: kwvg
PR: dashpay/dash#6761
File: src/chainlock/signing.h:5-6
Timestamp: 2025-07-23T09:30:34.592Z
Learning: Dash Core uses BITCOIN_ prefix for header guards as the standard convention, inherited from Bitcoin Core. Only a few BLS-specific files in src/bls/ use DASH_ prefix. The vast majority of files (385+) use BITCOIN_ prefix.

Learnt from: kwvg
PR: dashpay/dash#6761
File: src/chainlock/signing.cpp:15-250
Timestamp: 2025-07-23T09:28:32.758Z
Learning: In refactoring PRs like #6761, kwvg prefers to defer code formatting fixes to separate follow-up PRs when formatting is not the primary objective, to maintain focus on the structural changes and avoid scope creep.

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/{crc32c,dashbls,gsl,immer,leveldb,minisketch,secp256k1,univalue}/** : Do not make changes under any circumstances to vendored dependencies in src/crc32c, src/dashbls, src/gsl, src/immer, src/leveldb, src/minisketch, src/secp256k1, src/univalue

Learnt from: kwvg
PR: dashpay/dash#6752
File: src/wallet/load.cpp:164-164
Timestamp: 2025-07-17T15:48:29.418Z
Learning: In Dash Core, kwvg prefers using assert() statements to document expected behavior in code paths, especially when the called function also has internal asserts. This is used as a defensive programming pattern rather than requiring conditional error handling.

src/test/blockfilter_tests.cpp (1)

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/{test,wallet/test,qt/test}/**/*.{cpp,h,cc,cxx,hpp} : Unit tests for C++ code should be placed in src/test/, src/wallet/test/, or src/qt/test/ and use Boost::Test or Qt 5 for GUI tests

src/llmq/commitment.h (1)

Learnt from: kwvg
PR: #6665
File: src/evo/providertx.h:82-82
Timestamp: 2025-06-06T11:53:09.094Z
Learning: In ProTx serialization code (SERIALIZE_METHODS), version checks should use hardcoded maximum flags (/is_basic_scheme_active=/true, /is_extended_addr=/true) rather than deployment-based flags. This is because serialization code should be able to deserialize any structurally valid ProTx up to the maximum version the code knows how to handle, regardless of current consensus validity. Validation code, not serialization code, is responsible for checking whether a ProTx version is consensus-valid based on deployment status.

src/test/system_tests.cpp (2)

Learnt from: kwvg
PR: #6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/{test,wallet/test,qt/test}/**/*.{cpp,h,cc,cxx,hpp} : Unit tests for C++ code should be placed in src/test/, src/wallet/test/, or src/qt/test/ and use Boost::Test or Qt 5 for GUI tests

test/lint/lint-files.py (1)

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/{crc32c,dashbls,gsl,immer,leveldb,minisketch,secp256k1,univalue}/** : Do not make changes under any circumstances to vendored dependencies in src/crc32c, src/dashbls, src/gsl, src/immer, src/leveldb, src/minisketch, src/secp256k1, src/univalue

src/univalue/include/univalue_escapes.h (1)

Learnt from: kwvg
PR: #6761
File: src/chainlock/signing.h:5-6
Timestamp: 2025-07-23T09:30:34.592Z
Learning: Dash Core uses BITCOIN_ prefix for header guards as the standard convention, inherited from Bitcoin Core. Only a few BLS-specific files in src/bls/ use DASH_ prefix. The vast majority of files (385+) use BITCOIN_ prefix.

src/core_write.cpp (2)

Learnt from: kwvg
PR: #6665
File: src/evo/providertx.h:82-82
Timestamp: 2025-06-06T11:53:09.094Z
Learning: In ProTx serialization code (SERIALIZE_METHODS), version checks should use hardcoded maximum flags (/is_basic_scheme_active=/true, /is_extended_addr=/true) rather than deployment-based flags. This is because serialization code should be able to deserialize any structurally valid ProTx up to the maximum version the code knows how to handle, regardless of current consensus validity. Validation code, not serialization code, is responsible for checking whether a ProTx version is consensus-valid based on deployment status.

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/evo/specialtx.h : Special transactions use payload extensions defined in src/evo/specialtx.h

test/lint/lint-format-strings.py (2)

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/{crc32c,dashbls,gsl,immer,leveldb,minisketch,secp256k1,univalue}/** : Do not make changes under any circumstances to vendored dependencies in src/crc32c, src/dashbls, src/gsl, src/immer, src/leveldb, src/minisketch, src/secp256k1, src/univalue

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Always run linting before commits using test/lint/all-lint.py

src/test/sighash_tests.cpp (1)

Learnt from: kwvg
PR: #6665
File: src/evo/providertx.h:82-82
Timestamp: 2025-06-06T11:53:09.094Z
Learning: In ProTx serialization code (SERIALIZE_METHODS), version checks should use hardcoded maximum flags (/is_basic_scheme_active=/true, /is_extended_addr=/true) rather than deployment-based flags. This is because serialization code should be able to deserialize any structurally valid ProTx up to the maximum version the code knows how to handle, regardless of current consensus validity. Validation code, not serialization code, is responsible for checking whether a ProTx version is consensus-valid based on deployment status.

ci/test/wrap-wine.sh (2)

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/{test,wallet/test,qt/test}/**/*.{cpp,h,cc,cxx,hpp} : Unit tests for C++ code should be placed in src/test/, src/wallet/test/, or src/qt/test/ and use Boost::Test or Qt 5 for GUI tests

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/{crc32c,dashbls,gsl,immer,leveldb,minisketch,secp256k1,univalue}/** : Do not make changes under any circumstances to vendored dependencies in src/crc32c, src/dashbls, src/gsl, src/immer, src/leveldb, src/minisketch, src/secp256k1, src/univalue

src/wallet/rpc/encrypt.cpp (1)

Learnt from: kwvg
PR: #6529
File: src/wallet/rpcwallet.cpp:3002-3003
Timestamp: 2025-02-14T15:19:17.218Z
Learning: The GetWallet() function calls in src/wallet/rpcwallet.cpp are properly validated with null checks that throw appropriate RPC errors, making additional validation unnecessary.

src/masternode/meta.cpp (2)

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/{masternode,evo}/**/*.{cpp,h,cc,cxx,hpp} : Masternode lists must use immutable data structures (Immer library) for thread safety

Learnt from: kwvg
PR: #6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

src/evo/core_write.cpp (5)

Learnt from: kwvg
PR: #6665
File: src/evo/providertx.h:82-82
Timestamp: 2025-06-06T11:53:09.094Z
Learning: In ProTx serialization code (SERIALIZE_METHODS), version checks should use hardcoded maximum flags (/is_basic_scheme_active=/true, /is_extended_addr=/true) rather than deployment-based flags. This is because serialization code should be able to deserialize any structurally valid ProTx up to the maximum version the code knows how to handle, regardless of current consensus validity. Validation code, not serialization code, is responsible for checking whether a ProTx version is consensus-valid based on deployment status.

Learnt from: kwvg
PR: #6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

Learnt from: kwvg
PR: #6543
File: src/wallet/receive.cpp:240-251
Timestamp: 2025-02-06T14:34:30.466Z
Learning: Pull request #6543 is focused on move-only changes and refactoring, specifically backporting from Bitcoin. Behavior changes should be proposed in separate PRs.

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/{masternode,evo}/**/*.{cpp,h,cc,cxx,hpp} : Masternode lists must use immutable data structures (Immer library) for thread safety

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/evo/specialtx.h : Special transactions use payload extensions defined in src/evo/specialtx.h

src/bitcoin-tx.cpp (3)

Learnt from: kwvg
PR: #6665
File: src/evo/providertx.h:82-82
Timestamp: 2025-06-06T11:53:09.094Z
Learning: In ProTx serialization code (SERIALIZE_METHODS), version checks should use hardcoded maximum flags (/is_basic_scheme_active=/true, /is_extended_addr=/true) rather than deployment-based flags. This is because serialization code should be able to deserialize any structurally valid ProTx up to the maximum version the code knows how to handle, regardless of current consensus validity. Validation code, not serialization code, is responsible for checking whether a ProTx version is consensus-valid based on deployment status.

Learnt from: kwvg
PR: #6530
File: src/validation.cpp:360-362
Timestamp: 2025-01-14T08:37:16.955Z
Learning: The UpdateTransactionsFromBlock() method in txmempool.cpp takes parameters in the order: vHashUpdate, ancestor_size_limit, ancestor_count_limit. The size limit comes before the count limit.

Learnt from: kwvg
PR: #6729
File: src/evo/deterministicmns.cpp:1313-1316
Timestamp: 2025-07-09T15:02:26.899Z
Learning: In Dash's masternode transaction validation, IsVersionChangeValid() is only called by transaction types that update existing masternode entries (like ProUpServTx, ProUpRegTx, ProUpRevTx), not by ProRegTx which creates new entries. This means validation logic in IsVersionChangeValid() only applies to the subset of transaction types that actually call it, not all masternode transaction types.

src/test/fuzz/rpc.cpp (2)

Learnt from: kwvg
PR: #6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

Learnt from: kwvg
PR: #6529
File: src/wallet/rpcwallet.cpp:3002-3003
Timestamp: 2025-02-14T15:19:17.218Z
Learning: The GetWallet() function calls in src/wallet/rpcwallet.cpp are properly validated with null checks that throw appropriate RPC errors, making additional validation unnecessary.

src/univalue/test/test_json.cpp (1)

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/{test,wallet/test,qt/test}/**/*.{cpp,h,cc,cxx,hpp} : Unit tests for C++ code should be placed in src/test/, src/wallet/test/, or src/qt/test/ and use Boost::Test or Qt 5 for GUI tests

src/net_types.cpp (1)

Learnt from: kwvg
PR: #6629
File: src/evo/deterministicmns.cpp:473-485
Timestamp: 2025-05-10T00:54:15.597Z
Learning: In the current implementation of NetInfoEntry, only CService is a valid type and std::monostate represents an invalid state. Entries that don't provide a valid CService through GetAddrPort() should be rejected with an exception, not silently skipped.

src/wallet/rpc/spend.cpp (2)

Learnt from: kwvg
PR: #6529
File: src/wallet/rpcwallet.cpp:3002-3003
Timestamp: 2025-02-14T15:19:17.218Z
Learning: The GetWallet() function calls in src/wallet/rpcwallet.cpp are properly validated with null checks that throw appropriate RPC errors, making additional validation unnecessary.

Learnt from: kwvg
PR: #6543
File: src/wallet/receive.cpp:240-251
Timestamp: 2025-02-06T14:34:30.466Z
Learning: Pull request #6543 is focused on move-only changes and refactoring, specifically backporting from Bitcoin. Behavior changes should be proposed in separate PRs.

src/test/key_io_tests.cpp (2)

Learnt from: kwvg
PR: #6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/{test,wallet/test,qt/test}/**/*.{cpp,h,cc,cxx,hpp} : Unit tests for C++ code should be placed in src/test/, src/wallet/test/, or src/qt/test/ and use Boost::Test or Qt 5 for GUI tests

test/lint/lint-spelling.py (1)

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/{crc32c,dashbls,gsl,immer,leveldb,minisketch,secp256k1,univalue}/** : Do not make changes under any circumstances to vendored dependencies in src/crc32c, src/dashbls, src/gsl, src/immer, src/leveldb, src/minisketch, src/secp256k1, src/univalue

src/rpc/rawtransaction_util.cpp (4)

Learnt from: kwvg
PR: #6529
File: src/wallet/rpcwallet.cpp:3002-3003
Timestamp: 2025-02-14T15:19:17.218Z
Learning: The GetWallet() function calls in src/wallet/rpcwallet.cpp are properly validated with null checks that throw appropriate RPC errors, making additional validation unnecessary.

Learnt from: kwvg
PR: #6665
File: src/evo/providertx.h:82-82
Timestamp: 2025-06-06T11:53:09.094Z
Learning: In ProTx serialization code (SERIALIZE_METHODS), version checks should use hardcoded maximum flags (/is_basic_scheme_active=/true, /is_extended_addr=/true) rather than deployment-based flags. This is because serialization code should be able to deserialize any structurally valid ProTx up to the maximum version the code knows how to handle, regardless of current consensus validity. Validation code, not serialization code, is responsible for checking whether a ProTx version is consensus-valid based on deployment status.

Learnt from: kwvg
PR: #6543
File: src/wallet/receive.cpp:240-251
Timestamp: 2025-02-06T14:34:30.466Z
Learning: Pull request #6543 is focused on move-only changes and refactoring, specifically backporting from Bitcoin. Behavior changes should be proposed in separate PRs.

Learnt from: kwvg
PR: #6530
File: src/validation.cpp:360-362
Timestamp: 2025-01-14T08:37:16.955Z
Learning: The UpdateTransactionsFromBlock() method in txmempool.cpp takes parameters in the order: vHashUpdate, ancestor_size_limit, ancestor_count_limit. The size limit comes before the count limit.

src/rpc/masternode.cpp (3)

Learnt from: kwvg
PR: #6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/{masternode,evo}/**/*.{cpp,h,cc,cxx,hpp} : Masternode lists must use immutable data structures (Immer library) for thread safety

Learnt from: kwvg
PR: #6729
File: src/evo/deterministicmns.cpp:1313-1316
Timestamp: 2025-07-09T15:02:26.899Z
Learning: In Dash's masternode transaction validation, IsVersionChangeValid() is only called by transaction types that update existing masternode entries (like ProUpServTx, ProUpRegTx, ProUpRevTx), not by ProRegTx which creates new entries. This means validation logic in IsVersionChangeValid() only applies to the subset of transaction types that actually call it, not all masternode transaction types.

src/univalue/test/unitester.cpp (2)

Learnt from: kwvg
PR: #6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/{test,wallet/test,qt/test}/**/*.{cpp,h,cc,cxx,hpp} : Unit tests for C++ code should be placed in src/test/, src/wallet/test/, or src/qt/test/ and use Boost::Test or Qt 5 for GUI tests

src/Makefile.test.include (2)

Learnt from: kwvg
PR: #6516
File: depends/patches/gmp/include_ldflags_in_configure.patch:557-621
Timestamp: 2025-01-06T09:51:03.167Z
Learning: The GMP_GCC_ARM_UMODSI macro checks only the compiler version, and GMP_GCC_MIPS_O32 relies on the -mabi=32 flag. Therefore, $LDFLAGS is irrelevant to these tests.

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/{test,wallet/test,qt/test}/**/*.{cpp,h,cc,cxx,hpp} : Unit tests for C++ code should be placed in src/test/, src/wallet/test/, or src/qt/test/ and use Boost::Test or Qt 5 for GUI tests

src/rpc/util.cpp (3)

Learnt from: kwvg
PR: #6529
File: src/wallet/rpcwallet.cpp:3002-3003
Timestamp: 2025-02-14T15:19:17.218Z
Learning: The GetWallet() function calls in src/wallet/rpcwallet.cpp are properly validated with null checks that throw appropriate RPC errors, making additional validation unnecessary.

Learnt from: kwvg
PR: #6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

Learnt from: kwvg
PR: #6665
File: src/evo/providertx.h:82-82
Timestamp: 2025-06-06T11:53:09.094Z
Learning: In ProTx serialization code (SERIALIZE_METHODS), version checks should use hardcoded maximum flags (/is_basic_scheme_active=/true, /is_extended_addr=/true) rather than deployment-based flags. This is because serialization code should be able to deserialize any structurally valid ProTx up to the maximum version the code knows how to handle, regardless of current consensus validity. Validation code, not serialization code, is responsible for checking whether a ProTx version is consensus-valid based on deployment status.

src/wallet/rpc/addresses.cpp (3)

Learnt from: kwvg
PR: #6529
File: src/wallet/rpcwallet.cpp:3002-3003
Timestamp: 2025-02-14T15:19:17.218Z
Learning: The GetWallet() function calls in src/wallet/rpcwallet.cpp are properly validated with null checks that throw appropriate RPC errors, making additional validation unnecessary.

Learnt from: kwvg
PR: #6543
File: src/wallet/receive.cpp:240-251
Timestamp: 2025-02-06T14:34:30.466Z
Learning: Pull request #6543 is focused on move-only changes and refactoring, specifically backporting from Bitcoin. Behavior changes should be proposed in separate PRs.

Learnt from: kwvg
PR: #6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

src/httprpc.cpp (2)

Learnt from: kwvg
PR: #6529
File: src/wallet/rpcwallet.cpp:3002-3003
Timestamp: 2025-02-14T15:19:17.218Z
Learning: The GetWallet() function calls in src/wallet/rpcwallet.cpp are properly validated with null checks that throw appropriate RPC errors, making additional validation unnecessary.

Learnt from: kwvg
PR: #6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

configure.ac (2)

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/**/*.{cpp,h,cc,cxx,hpp} : Dash Core C++ codebase must be written in C++20 and require at least Clang 16 or GCC 11.1

Learnt from: kwvg
PR: #6516
File: depends/patches/gmp/include_ldflags_in_configure.patch:557-621
Timestamp: 2025-01-06T09:51:03.167Z
Learning: The GMP_GCC_ARM_UMODSI macro checks only the compiler version, and GMP_GCC_MIPS_O32 relies on the -mabi=32 flag. Therefore, $LDFLAGS is irrelevant to these tests.

src/node/interfaces.cpp (2)

Learnt from: kwvg
PR: #6529
File: src/wallet/rpcwallet.cpp:3002-3003
Timestamp: 2025-02-14T15:19:17.218Z
Learning: The GetWallet() function calls in src/wallet/rpcwallet.cpp are properly validated with null checks that throw appropriate RPC errors, making additional validation unnecessary.

Learnt from: kwvg
PR: #6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

src/rpc/mempool.cpp (4)

Learnt from: kwvg
PR: #6543
File: src/wallet/receive.cpp:240-251
Timestamp: 2025-02-06T14:34:30.466Z
Learning: Pull request #6543 is focused on move-only changes and refactoring, specifically backporting from Bitcoin. Behavior changes should be proposed in separate PRs.

Learnt from: kwvg
PR: #6529
File: src/wallet/rpcwallet.cpp:3002-3003
Timestamp: 2025-02-14T15:19:17.218Z
Learning: The GetWallet() function calls in src/wallet/rpcwallet.cpp are properly validated with null checks that throw appropriate RPC errors, making additional validation unnecessary.

Learnt from: kwvg
PR: #6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

Learnt from: kwvg
PR: #6665
File: src/evo/providertx.h:82-82
Timestamp: 2025-06-06T11:53:09.094Z
Learning: In ProTx serialization code (SERIALIZE_METHODS), version checks should use hardcoded maximum flags (/is_basic_scheme_active=/true, /is_extended_addr=/true) rather than deployment-based flags. This is because serialization code should be able to deserialize any structurally valid ProTx up to the maximum version the code knows how to handle, regardless of current consensus validity. Validation code, not serialization code, is responsible for checking whether a ProTx version is consensus-valid based on deployment status.

test/lint/lint-shell-locale.py (1)

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/{crc32c,dashbls,gsl,immer,leveldb,minisketch,secp256k1,univalue}/** : Do not make changes under any circumstances to vendored dependencies in src/crc32c, src/dashbls, src/gsl, src/immer, src/leveldb, src/minisketch, src/secp256k1, src/univalue

src/qt/rpcconsole.cpp (1)

Learnt from: kwvg
PR: #6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

src/wallet/rpc/coins.cpp (3)

Learnt from: kwvg
PR: #6529
File: src/wallet/rpcwallet.cpp:3002-3003
Timestamp: 2025-02-14T15:19:17.218Z
Learning: The GetWallet() function calls in src/wallet/rpcwallet.cpp are properly validated with null checks that throw appropriate RPC errors, making additional validation unnecessary.

Learnt from: kwvg
PR: #6543
File: src/wallet/receive.cpp:240-251
Timestamp: 2025-02-06T14:34:30.466Z
Learning: Pull request #6543 is focused on move-only changes and refactoring, specifically backporting from Bitcoin. Behavior changes should be proposed in separate PRs.

Learnt from: kwvg
PR: #6530
File: src/validation.cpp:360-362
Timestamp: 2025-01-14T08:37:16.955Z
Learning: The UpdateTransactionsFromBlock() method in txmempool.cpp takes parameters in the order: vHashUpdate, ancestor_size_limit, ancestor_count_limit. The size limit comes before the count limit.

src/rpc/blockchain.cpp (6)

Learnt from: kwvg
PR: #6543
File: src/wallet/receive.cpp:240-251
Timestamp: 2025-02-06T14:34:30.466Z
Learning: Pull request #6543 is focused on move-only changes and refactoring, specifically backporting from Bitcoin. Behavior changes should be proposed in separate PRs.

Learnt from: kwvg
PR: #6529
File: src/wallet/rpcwallet.cpp:3002-3003
Timestamp: 2025-02-14T15:19:17.218Z
Learning: The GetWallet() function calls in src/wallet/rpcwallet.cpp are properly validated with null checks that throw appropriate RPC errors, making additional validation unnecessary.

Learnt from: kwvg
PR: #6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

Learnt from: kwvg
PR: #6530
File: src/validation.cpp:360-362
Timestamp: 2025-01-14T08:37:16.955Z
Learning: The UpdateTransactionsFromBlock() method in txmempool.cpp takes parameters in the order: vHashUpdate, ancestor_size_limit, ancestor_count_limit. The size limit comes before the count limit.

Learnt from: kwvg
PR: #6665
File: src/evo/providertx.h:82-82
Timestamp: 2025-06-06T11:53:09.094Z
Learning: In ProTx serialization code (SERIALIZE_METHODS), version checks should use hardcoded maximum flags (/is_basic_scheme_active=/true, /is_extended_addr=/true) rather than deployment-based flags. This is because serialization code should be able to deserialize any structurally valid ProTx up to the maximum version the code knows how to handle, regardless of current consensus validity. Validation code, not serialization code, is responsible for checking whether a ProTx version is consensus-valid based on deployment status.

Learnt from: knst
PR: #6658
File: src/evo/creditpool.cpp:177-185
Timestamp: 2025-05-05T12:45:44.781Z
Learning: The GetAncestor() function in CBlockIndex safely handles negative heights by returning nullptr rather than asserting, making it safe to call with potentially negative values.

src/wallet/rpc/wallet.cpp (4)

Learnt from: kwvg
PR: #6529
File: src/wallet/rpcwallet.cpp:3002-3003
Timestamp: 2025-02-14T15:19:17.218Z
Learning: The GetWallet() function calls in src/wallet/rpcwallet.cpp are properly validated with null checks that throw appropriate RPC errors, making additional validation unnecessary.

Learnt from: kwvg
PR: #6543
File: src/wallet/receive.cpp:240-251
Timestamp: 2025-02-06T14:34:30.466Z
Learning: Pull request #6543 is focused on move-only changes and refactoring, specifically backporting from Bitcoin. Behavior changes should be proposed in separate PRs.

Learnt from: kwvg
PR: #6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

Learnt from: kwvg
PR: #6665
File: src/evo/providertx.h:82-82
Timestamp: 2025-06-06T11:53:09.094Z
Learning: In ProTx serialization code (SERIALIZE_METHODS), version checks should use hardcoded maximum flags (/is_basic_scheme_active=/true, /is_extended_addr=/true) rather than deployment-based flags. This is because serialization code should be able to deserialize any structurally valid ProTx up to the maximum version the code knows how to handle, regardless of current consensus validity. Validation code, not serialization code, is responsible for checking whether a ProTx version is consensus-valid based on deployment status.

src/rpc/governance.cpp (3)

Learnt from: kwvg
PR: #6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

Learnt from: kwvg
PR: #6529
File: src/wallet/rpcwallet.cpp:3002-3003
Timestamp: 2025-02-14T15:19:17.218Z
Learning: The GetWallet() function calls in src/wallet/rpcwallet.cpp are properly validated with null checks that throw appropriate RPC errors, making additional validation unnecessary.

Learnt from: knst
PR: #6658
File: src/evo/creditpool.cpp:177-185
Timestamp: 2025-05-05T12:45:44.781Z
Learning: The GetAncestor() function in CBlockIndex safely handles negative heights by returning nullptr rather than asserting, making it safe to call with potentially negative values.

src/rpc/mining.cpp (5)

Learnt from: kwvg
PR: #6529
File: src/wallet/rpcwallet.cpp:3002-3003
Timestamp: 2025-02-14T15:19:17.218Z
Learning: The GetWallet() function calls in src/wallet/rpcwallet.cpp are properly validated with null checks that throw appropriate RPC errors, making additional validation unnecessary.

Learnt from: kwvg
PR: #6543
File: src/wallet/receive.cpp:240-251
Timestamp: 2025-02-06T14:34:30.466Z
Learning: Pull request #6543 is focused on move-only changes and refactoring, specifically backporting from Bitcoin. Behavior changes should be proposed in separate PRs.

Learnt from: kwvg
PR: #6665
File: src/evo/providertx.h:82-82
Timestamp: 2025-06-06T11:53:09.094Z
Learning: In ProTx serialization code (SERIALIZE_METHODS), version checks should use hardcoded maximum flags (/is_basic_scheme_active=/true, /is_extended_addr=/true) rather than deployment-based flags. This is because serialization code should be able to deserialize any structurally valid ProTx up to the maximum version the code knows how to handle, regardless of current consensus validity. Validation code, not serialization code, is responsible for checking whether a ProTx version is consensus-valid based on deployment status.

Learnt from: kwvg
PR: #6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

Learnt from: kwvg
PR: #6530
File: src/validation.cpp:360-362
Timestamp: 2025-01-14T08:37:16.955Z
Learning: The UpdateTransactionsFromBlock() method in txmempool.cpp takes parameters in the order: vHashUpdate, ancestor_size_limit, ancestor_count_limit. The size limit comes before the count limit.

src/test/rpc_tests.cpp (6)

Learnt from: kwvg
PR: #6529
File: src/wallet/rpcwallet.cpp:3002-3003
Timestamp: 2025-02-14T15:19:17.218Z
Learning: The GetWallet() function calls in src/wallet/rpcwallet.cpp are properly validated with null checks that throw appropriate RPC errors, making additional validation unnecessary.

Learnt from: kwvg
PR: #6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/{test,wallet/test,qt/test}/**/*.{cpp,h,cc,cxx,hpp} : Unit tests for C++ code should be placed in src/test/, src/wallet/test/, or src/qt/test/ and use Boost::Test or Qt 5 for GUI tests

Learnt from: kwvg
PR: #6665
File: src/evo/providertx.h:82-82
Timestamp: 2025-06-06T11:53:09.094Z
Learning: In ProTx serialization code (SERIALIZE_METHODS), version checks should use hardcoded maximum flags (/is_basic_scheme_active=/true, /is_extended_addr=/true) rather than deployment-based flags. This is because serialization code should be able to deserialize any structurally valid ProTx up to the maximum version the code knows how to handle, regardless of current consensus validity. Validation code, not serialization code, is responsible for checking whether a ProTx version is consensus-valid based on deployment status.

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/evo/specialtx.h : Special transactions use payload extensions defined in src/evo/specialtx.h

Learnt from: kwvg
PR: #6629
File: src/evo/deterministicmns.cpp:473-485
Timestamp: 2025-05-10T00:54:15.597Z
Learning: In the current implementation of NetInfoEntry, only CService is a valid type and std::monostate represents an invalid state. Entries that don't provide a valid CService through GetAddrPort() should be rejected with an exception, not silently skipped.

src/univalue/sources.mk (1)

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/{test,wallet/test,qt/test}/**/*.{cpp,h,cc,cxx,hpp} : Unit tests for C++ code should be placed in src/test/, src/wallet/test/, or src/qt/test/ and use Boost::Test or Qt 5 for GUI tests

src/test/transaction_tests.cpp (5)

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/{test,wallet/test,qt/test}/**/*.{cpp,h,cc,cxx,hpp} : Unit tests for C++ code should be placed in src/test/, src/wallet/test/, or src/qt/test/ and use Boost::Test or Qt 5 for GUI tests

Learnt from: kwvg
PR: #6529
File: src/wallet/rpcwallet.cpp:3002-3003
Timestamp: 2025-02-14T15:19:17.218Z
Learning: The GetWallet() function calls in src/wallet/rpcwallet.cpp are properly validated with null checks that throw appropriate RPC errors, making additional validation unnecessary.

Learnt from: kwvg
PR: #6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

Learnt from: kwvg
PR: #6665
File: src/evo/providertx.h:82-82
Timestamp: 2025-06-06T11:53:09.094Z
Learning: In ProTx serialization code (SERIALIZE_METHODS), version checks should use hardcoded maximum flags (/is_basic_scheme_active=/true, /is_extended_addr=/true) rather than deployment-based flags. This is because serialization code should be able to deserialize any structurally valid ProTx up to the maximum version the code knows how to handle, regardless of current consensus validity. Validation code, not serialization code, is responsible for checking whether a ProTx version is consensus-valid based on deployment status.

Learnt from: kwvg
PR: #6530
File: src/validation.cpp:360-362
Timestamp: 2025-01-14T08:37:16.955Z
Learning: The UpdateTransactionsFromBlock() method in txmempool.cpp takes parameters in the order: vHashUpdate, ancestor_size_limit, ancestor_count_limit. The size limit comes before the count limit.

src/rpc/quorums.cpp (5)

Learnt from: kwvg
PR: #6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

Learnt from: kwvg
PR: #6529
File: src/wallet/rpcwallet.cpp:3002-3003
Timestamp: 2025-02-14T15:19:17.218Z
Learning: The GetWallet() function calls in src/wallet/rpcwallet.cpp are properly validated with null checks that throw appropriate RPC errors, making additional validation unnecessary.

Learnt from: kwvg
PR: #6543
File: src/wallet/receive.cpp:240-251
Timestamp: 2025-02-06T14:34:30.466Z
Learning: Pull request #6543 is focused on move-only changes and refactoring, specifically backporting from Bitcoin. Behavior changes should be proposed in separate PRs.

Learnt from: knst
PR: #6658
File: src/evo/creditpool.cpp:177-185
Timestamp: 2025-05-05T12:45:44.781Z
Learning: The GetAncestor() function in CBlockIndex safely handles negative heights by returning nullptr rather than asserting, making it safe to call with potentially negative values.

Learnt from: kwvg
PR: #6530
File: src/validation.cpp:360-362
Timestamp: 2025-01-14T08:37:16.955Z
Learning: The UpdateTransactionsFromBlock() method in txmempool.cpp takes parameters in the order: vHashUpdate, ancestor_size_limit, ancestor_count_limit. The size limit comes before the count limit.

src/evo/deterministicmns.cpp (3)

Learnt from: knst
PR: #6511
File: src/evo/deterministicmns.cpp:1369-1373
Timestamp: 2025-01-07T18:50:44.838Z
Learning: The functions MigrateDBIfNeeded and MigrateDBIfNeeded2 in src/evo/deterministicmns.cpp are temporary and will be removed in a future version. Refactoring suggestions for these functions should be avoided.

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/{masternode,evo}/**/*.{cpp,h,cc,cxx,hpp} : Masternode lists must use immutable data structures (Immer library) for thread safety

Learnt from: kwvg
PR: #6665
File: src/evo/providertx.h:82-82
Timestamp: 2025-06-06T11:53:09.094Z
Learning: In ProTx serialization code (SERIALIZE_METHODS), version checks should use hardcoded maximum flags (/is_basic_scheme_active=/true, /is_extended_addr=/true) rather than deployment-based flags. This is because serialization code should be able to deserialize any structurally valid ProTx up to the maximum version the code knows how to handle, regardless of current consensus validity. Validation code, not serialization code, is responsible for checking whether a ProTx version is consensus-valid based on deployment status.

src/rpc/net.cpp (2)

Learnt from: kwvg
PR: #6529
File: src/wallet/rpcwallet.cpp:3002-3003
Timestamp: 2025-02-14T15:19:17.218Z
Learning: The GetWallet() function calls in src/wallet/rpcwallet.cpp are properly validated with null checks that throw appropriate RPC errors, making additional validation unnecessary.

Learnt from: kwvg
PR: #6629
File: src/evo/deterministicmns.cpp:473-485
Timestamp: 2025-05-10T00:54:15.597Z
Learning: In the current implementation of NetInfoEntry, only CService is a valid type and std::monostate represents an invalid state. Entries that don't provide a valid CService through GetAddrPort() should be rejected with an exception, not silently skipped.

src/bitcoin-cli.cpp (6)

Learnt from: kwvg
PR: #6529
File: src/wallet/rpcwallet.cpp:3002-3003
Timestamp: 2025-02-14T15:19:17.218Z
Learning: The GetWallet() function calls in src/wallet/rpcwallet.cpp are properly validated with null checks that throw appropriate RPC errors, making additional validation unnecessary.

Learnt from: kwvg
PR: #6665
File: src/evo/providertx.h:82-82
Timestamp: 2025-06-06T11:53:09.094Z
Learning: In ProTx serialization code (SERIALIZE_METHODS), version checks should use hardcoded maximum flags (/is_basic_scheme_active=/true, /is_extended_addr=/true) rather than deployment-based flags. This is because serialization code should be able to deserialize any structurally valid ProTx up to the maximum version the code knows how to handle, regardless of current consensus validity. Validation code, not serialization code, is responsible for checking whether a ProTx version is consensus-valid based on deployment status.

Learnt from: kwvg
PR: #6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

Learnt from: kwvg
PR: #6543
File: src/wallet/receive.cpp:240-251
Timestamp: 2025-02-06T14:34:30.466Z
Learning: Pull request #6543 is focused on move-only changes and refactoring, specifically backporting from Bitcoin. Behavior changes should be proposed in separate PRs.

Learnt from: kwvg
PR: #6629
File: src/evo/deterministicmns.cpp:473-485
Timestamp: 2025-05-10T00:54:15.597Z
Learning: In the current implementation of NetInfoEntry, only CService is a valid type and std::monostate represents an invalid state. Entries that don't provide a valid CService through GetAddrPort() should be rejected with an exception, not silently skipped.

Learnt from: kwvg
PR: #6530
File: src/validation.cpp:4514-4516
Timestamp: 2025-01-14T08:40:00.994Z
Learning: In Dash Core, error() is used (instead of state.Invalid()) to report critical failures that require immediate user intervention, particularly for database/disk errors and data corruption scenarios. This is an established pattern seen in validation.cpp.

src/univalue/include/univalue_utffilter.h (1)

Learnt from: kwvg
PR: #6761
File: src/chainlock/signing.h:5-6
Timestamp: 2025-07-23T09:30:34.592Z
Learning: Dash Core uses BITCOIN_ prefix for header guards as the standard convention, inherited from Bitcoin Core. Only a few BLS-specific files in src/bls/ use DASH_ prefix. The vast majority of files (385+) use BITCOIN_ prefix.

src/wallet/rpc/transactions.cpp (3)

Learnt from: kwvg
PR: #6529
File: src/wallet/rpcwallet.cpp:3002-3003
Timestamp: 2025-02-14T15:19:17.218Z
Learning: The GetWallet() function calls in src/wallet/rpcwallet.cpp are properly validated with null checks that throw appropriate RPC errors, making additional validation unnecessary.

Learnt from: kwvg
PR: #6530
File: src/validation.cpp:360-362
Timestamp: 2025-01-14T08:37:16.955Z
Learning: The UpdateTransactionsFromBlock() method in txmempool.cpp takes parameters in the order: vHashUpdate, ancestor_size_limit, ancestor_count_limit. The size limit comes before the count limit.

Learnt from: knst
PR: #6658
File: src/evo/creditpool.cpp:177-185
Timestamp: 2025-05-05T12:45:44.781Z
Learning: The GetAncestor() function in CBlockIndex safely handles negative heights by returning nullptr rather than asserting, making it safe to call with potentially negative values.

src/governance/governance.cpp (2)

Learnt from: kwvg
PR: #6543
File: src/wallet/receive.cpp:240-251
Timestamp: 2025-02-06T14:34:30.466Z
Learning: Pull request #6543 is focused on move-only changes and refactoring, specifically backporting from Bitcoin. Behavior changes should be proposed in separate PRs.

Learnt from: kwvg
PR: #6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

src/rpc/node.cpp (5)

Learnt from: kwvg
PR: #6543
File: src/wallet/receive.cpp:240-251
Timestamp: 2025-02-06T14:34:30.466Z
Learning: Pull request #6543 is focused on move-only changes and refactoring, specifically backporting from Bitcoin. Behavior changes should be proposed in separate PRs.

Learnt from: kwvg
PR: #6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

Learnt from: kwvg
PR: #6529
File: src/wallet/rpcwallet.cpp:3002-3003
Timestamp: 2025-02-14T15:19:17.218Z
Learning: The GetWallet() function calls in src/wallet/rpcwallet.cpp are properly validated with null checks that throw appropriate RPC errors, making additional validation unnecessary.

Learnt from: kwvg
PR: #6530
File: src/validation.cpp:360-362
Timestamp: 2025-01-14T08:37:16.955Z
Learning: The UpdateTransactionsFromBlock() method in txmempool.cpp takes parameters in the order: vHashUpdate, ancestor_size_limit, ancestor_count_limit. The size limit comes before the count limit.

Learnt from: kwvg
PR: #6665
File: src/evo/deterministicmns.cpp:1284-1287
Timestamp: 2025-06-16T17:59:55.669Z
Learning: In Dash masternode ProRegTx validation, platform ports (platformHTTPPort and platformP2PPort) are mandatory and must be non-zero, while netInfo (ipAndPort) is optional. This means that even if an empty netInfo returns 0 from GetPrimary().GetPort(), it won't cause false positives in port duplication checks since platform ports cannot be 0.

src/rpc/rawtransaction.cpp (3)

Learnt from: kwvg
PR: #6529
File: src/wallet/rpcwallet.cpp:3002-3003
Timestamp: 2025-02-14T15:19:17.218Z
Learning: The GetWallet() function calls in src/wallet/rpcwallet.cpp are properly validated with null checks that throw appropriate RPC errors, making additional validation unnecessary.

Learnt from: kwvg
PR: #6665
File: src/evo/providertx.h:82-82
Timestamp: 2025-06-06T11:53:09.094Z
Learning: In ProTx serialization code (SERIALIZE_METHODS), version checks should use hardcoded maximum flags (/is_basic_scheme_active=/true, /is_extended_addr=/true) rather than deployment-based flags. This is because serialization code should be able to deserialize any structurally valid ProTx up to the maximum version the code knows how to handle, regardless of current consensus validity. Validation code, not serialization code, is responsible for checking whether a ProTx version is consensus-valid based on deployment status.

Learnt from: knst
PR: #6658
File: src/evo/creditpool.cpp:177-185
Timestamp: 2025-05-05T12:45:44.781Z
Learning: The GetAncestor() function in CBlockIndex safely handles negative heights by returning nullptr rather than asserting, making it safe to call with potentially negative values.

src/rpc/client.cpp (1)

Learnt from: kwvg
PR: #6529
File: src/wallet/rpcwallet.cpp:3002-3003
Timestamp: 2025-02-14T15:19:17.218Z
Learning: The GetWallet() function calls in src/wallet/rpcwallet.cpp are properly validated with null checks that throw appropriate RPC errors, making additional validation unnecessary.

src/wallet/test/wallet_tests.cpp (3)

Learnt from: kwvg
PR: #6529
File: src/wallet/rpcwallet.cpp:3002-3003
Timestamp: 2025-02-14T15:19:17.218Z
Learning: The GetWallet() function calls in src/wallet/rpcwallet.cpp are properly validated with null checks that throw appropriate RPC errors, making additional validation unnecessary.

Learnt from: kwvg
PR: #6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/{test,wallet/test,qt/test}/**/*.{cpp,h,cc,cxx,hpp} : Unit tests for C++ code should be placed in src/test/, src/wallet/test/, or src/qt/test/ and use Boost::Test or Qt 5 for GUI tests

src/wallet/rpc/backup.cpp (1)

Learnt from: kwvg
PR: #6529
File: src/wallet/rpcwallet.cpp:3002-3003
Timestamp: 2025-02-14T15:19:17.218Z
Learning: The GetWallet() function calls in src/wallet/rpcwallet.cpp are properly validated with null checks that throw appropriate RPC errors, making additional validation unnecessary.

src/univalue/test/object.cpp (2)

Learnt from: CR
PR: dashpay/dash#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T18:42:49.794Z
Learning: Applies to src/{test,wallet/test,qt/test}/**/*.{cpp,h,cc,cxx,hpp} : Unit tests for C++ code should be placed in src/test/, src/wallet/test/, or src/qt/test/ and use Boost::Test or Qt 5 for GUI tests

Learnt from: kwvg
PR: #6718
File: test/functional/test_framework/test_framework.py:2102-2102
Timestamp: 2025-06-09T16:43:20.996Z
Learning: In the test framework consolidation PR (#6718), user kwvg prefers to limit functional changes to those directly related to MasternodeInfo, avoiding scope creep even for minor improvements like error handling consistency.

🧬 Code Graph Analysis (4)

src/wallet/rpc/addresses.cpp (2)

src/qt/rpcconsole.cpp (2)

request (422-476)

request (422-422)

src/rpc/request.cpp (3)

request (31-31)

JSONRPCError (56-62)

JSONRPCError (56-56)

src/wallet/rpc/wallet.cpp (2)

src/node/interfaces.cpp (6)

nRounds (262-265)

nRounds (262-262)

nAmount (286-289)

nAmount (286-286)

nAmount (302-305)

nAmount (302-302)

src/core_write.cpp (2)

ValueFromAmount (36-47)

ValueFromAmount (36-36)

src/rpc/client.h (1)

src/rpc/client.cpp (2)

ParseNonRFCJSONValue (293-298)

ParseNonRFCJSONValue (293-293)

src/wallet/test/wallet_tests.cpp (1)

src/wallet/rpc/addresses.cpp (5)

getaddressinfo (420-561)

getaddressinfo (420-420)

labels (551-551)

pubkeys (369-369)

addresses (370-370)

🪛 GitHub Actions: Clang Diff Format Check

src/rpc/governance.cpp

[error] 1028-1055: Clang format differences found. The code formatting does not match the expected style. Please run clang-format to fix formatting issues.

🪛 Gitleaks (8.27.2)

src/test/rpc_tests.cpp

590-590: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.

(generic-api-key)

🔇 Additional comments (150)

ci/test/wrap-wine.sh (1)

9-9: LGTM - Consistent with UniValue subtree removal.

The removal of no_nul from the executable list aligns with the deletion of src/univalue/test/no_nul.cpp and related build targets as part of the UniValue subtree cleanup.

configure.ac (1)

453-460: LGTM - Successfully removes GCC warning suppression as intended.

This change fulfills the main PR objective of removing the -Wdangling-reference suppression that was introduced in Dash PR #6639. With the UniValue subtree removal and integration, this warning suppression is no longer needed.

src/univalue/sources.mk (2)

5-5: Comment update is consistent with makefile cleanup.

The shortened comment aligns with the broader UniValue build system cleanup.

11-12: Header reorganization aligns with subtree integration.

Moving univalue_utffilter.h and univalue_escapes.h to UNIVALUE_DIST_HEADERS_INT is consistent with the UniValue subtree integration and removal of internal header categorization.

test/lint/lint-spelling.py (1)

15-15: LGTM - Integrates UniValue into spell checking.

Removing src/univalue/ from the exclusion list is consistent with treating UniValue as integrated code rather than an external subtree, ensuring spell checking coverage across the entire codebase.

src/test/blockfilter_tests.cpp (1)

151-151: LGTM - Modernizes UniValue API usage.

The replacement of get_int() with getInt<int>() aligns with the UniValue API modernization, using the templated type-safe getter method instead of the deprecated function.

src/llmq/commitment.h (1)

125-125: Good modernization of UniValue usage.

Removing the explicit cast to int is appropriate since UniValue can handle uint16_t directly. This change aligns with the broader UniValue API modernization effort across the codebase.

src/evo/deterministicmns.cpp (1)

59-59: Appropriate removal of unnecessary cast.

Removing the explicit cast to int is correct since UniValue can handle uint32_t directly. This change is consistent with the broader UniValue API modernization effort.

src/test/sighash_tests.cpp (1)

183-184: Correct modernization of UniValue integer extraction.

The replacement of get_int() with getInt<int>() is appropriate and aligns with the new templated UniValue API that provides better type safety. The functionality remains unchanged.

test/lint/lint-format-strings.py (1)

80-80: Correct inclusion of univalue in format string linting.

Removing univalue from the exclusion pattern is appropriate now that the src/univalue subtree has been integrated into the main codebase. This ensures comprehensive linting coverage for the univalue code.

test/lint/lint-shell.py (1)

71-71: LGTM: Correctly includes univalue files in shell linting.

The removal of univalue from the exclusion regex aligns with the PR objective to integrate univalue into the main codebase. Shell scripts in src/univalue/ will now be properly linted.

src/governance/validators.cpp (1)

271-271: LGTM: API modernization to templated method.

The change from get_int64() to getInt<int64_t>() correctly adopts the modernized UniValue API with improved type safety while maintaining identical functionality.

src/test/system_tests.cpp (2)

39-39: LGTM: Updated to member function API.

The change from find_value(result, "success") to result.find_value("success") correctly adopts the modernized UniValue API while maintaining identical functionality.

93-93: LGTM: Consistent API update.

This change maintains consistency with the previous update, correctly using the member function API for finding JSON values.

test/lint/lint-files.py (1)

24-24: LGTM: Correctly subjects univalue files to standard linting.

The removal of univalue/ from the filename exception regex aligns with the PR objective to integrate univalue into the main codebase. Files in src/univalue/ will now follow standard naming conventions.

src/util/settings.h (1)

23-23: LGTM: Documentation updated for API consistency.

The comment correctly updates from get_int64() to getInt<int64_t>() to reflect the modernized UniValue API, maintaining accurate documentation.

src/rpc/masternode.cpp (1)

183-183: LGTM! Modernized UniValue usage by removing unnecessary cast.

The removal of the explicit (int) cast is appropriate since UniValue's pushKV can handle uint32_t directly. This change aligns with the broader UniValue API modernization across the codebase.

test/lint/lint-shell-locale.py (1)

44-44: LGTM! Correctly removes univalue from lint exclusions.

This change aligns with the removal of the src/univalue subtree. Shell scripts under src/univalue/ will now be subject to the same locale lint verification as the rest of the codebase.

src/test/transaction_tests.cpp (1)

182-182: LGTM! Updated to use templated UniValue integer accessor.

Both changes correctly replace the deprecated get_int() method with the type-safe templated getInt<int>() method. This modernizes the UniValue API usage while maintaining identical functionality.

Also applies to: 266-266

src/rpc/client.h (2)

9-10: LGTM! Added necessary headers for modernized function signature.

The addition of <string> and <string_view> headers is required to support the updated ParseNonRFCJSONValue function signature.

23-23: LGTM! Modernized parameter type for better performance.

Changing from const std::string& to std::string_view avoids unnecessary string copying and aligns with the implementation in src/rpc/client.cpp (lines 292-297). This improves efficiency while maintaining the same functionality.

src/wallet/rpc/addresses.cpp (2)

235-235: LGTM! Updated to use templated UniValue integer accessor in addmultisigaddress.

The change from get_int() to getInt<int>() modernizes the UniValue API usage while maintaining identical functionality for extracting the required number of signatures.

292-294: LGTM! Updated to use templated UniValue integer accessor in keypoolrefill.

Both changes correctly replace get_int() with getInt<int>() for extracting the keypool size parameter. The type-safe templated method is consistent with the modernized UniValue API across the codebase.

src/wallet/rpc/encrypt.cpp (1)

59-59: LGTM! UniValue API modernization.

The change from get_int64() to the templated getInt<int64_t>() method aligns with the broader UniValue API modernization in this PR. This improves type safety while maintaining the same functionality.

src/masternode/meta.cpp (1)

39-45: Excellent thread safety improvement.

Adding .load() calls to access atomic member variables ensures thread-safe reads when serializing masternode metadata to JSON. This prevents potential race conditions and aligns with the coding guidelines requiring thread safety in masternode code.

src/univalue/lib/univalue_write.cpp (1)

5-10: Confirm UniValue Integration Status

No .gitmodules file or “subtree” merge commits were found, suggesting UniValue may no longer be maintained as an external subtree. Before approving these header updates under src/univalue, please verify:

Is UniValue still treated as a vendored dependency?

If it remains vendored, revert changes in src/univalue/lib/univalue_write.cpp to preserve the original headers.

If it’s been fully integrated (no longer a subtree), the new includes are acceptable as part of the integration effort.

src/core_write.cpp (2)

273-273: Good simplification by removing unnecessary cast.

Removing the explicit (int) cast when pushing spentInfo.m_tx_index to UniValue simplifies the code. The underlying type should be compatible with UniValue's expectations.

286-286: Consistent cast removal improvement.

Removing the explicit cast when pushing tx.vExtraPayload.size() is consistent with the PR's pattern of eliminating unnecessary type conversions. UniValue should handle the size_t type appropriately.

src/rpc/output_script.cpp (1)

108-108: LGTM! UniValue API modernization correctly applied.

The replacement of get_int() with getInt<int>() aligns with the UniValue API modernization described in the PR objectives. This change improves type safety while maintaining the same functionality.

src/test/key_io_tests.cpp (2)

40-44: LGTM! Correct migration to UniValue member function API.

The replacement of global find_value(metadata, key) calls with metadata.find_value(key) member function calls correctly implements the UniValue API modernization. The test logic remains unchanged.

99-102: LGTM! Consistent API modernization applied.

The changes consistently apply the new UniValue member function API, replacing global find_value calls with member function calls. This maintains test functionality while using the modernized API.

src/bitcoin-tx.cpp (1)

572-572: LGTM! UniValue API modernization correctly implemented.

The replacement of get_int() with getInt<int>() follows the established pattern of UniValue API modernization throughout the codebase. This change improves type safety while maintaining the same functionality for extracting the vout index from the previous output JSON.

src/rpc/mempool.cpp (1)

398-399: LGTM! Simplified UniValue usage by removing unnecessary casts.

The removal of explicit integer casts when pushing values into UniValue JSON objects simplifies the code and aligns with the UniValue API modernization. The native return types from GetInstantSendLockCount() and GetUnbroadcastTxs().size() can now be used directly.

src/wallet/rpc/spend.cpp (2)

420-420: LGTM: API modernization for type safety

The replacement of get_int() with getInt<int>() aligns with the UniValue API modernization and provides explicit type safety.

513-513: LGTM: Consistent API modernization

The templated getInt<int>() method provides type-safe integer extraction from the UniValue array, consistent with the codebase-wide API updates.

src/rpc/server.cpp (1)

197-197: LGTM: Type-safe parameter extraction

The replacement with getInt<int>() provides explicit type safety for the wait parameter extraction, consistent with the UniValue API modernization across the codebase.

src/governance/object.cpp (1)

315-315: LGTM: Governance object type extraction modernized

The templated getInt<int>() method provides type-safe extraction of the governance object type from JSON, aligning with the repository-wide UniValue API updates.

src/univalue/lib/univalue_read.cpp (2)

5-11: LGTM: Header modernization aligns with C++20 standards.

The changes modernize header includes by:

Replacing C-style headers (<string.h>, <stdio.h>) with C++ standard library equivalents (<cstring>, <cstdio>, <cstdint>, <string>)

Converting local includes to system-style includes ("univalue.h" → <univalue.h>)

This aligns with the C++20 requirement specified in the coding guidelines.

20-20: LGTM: Proper use of constexpr for compile-time constant.

Converting static const size_t MAX_JSON_DEPTH = 512 to static constexpr size_t allows compile-time evaluation and better optimization, which is appropriate for a constant value.

src/test/fuzz/rpc.cpp (1)

359-359: LGTM: UniValue API modernization.

The change from find_value(json_rpc_error, "message") to json_rpc_error.find_value("message") correctly updates to the new member function API, maintaining the same functionality while improving code clarity and consistency.

src/qt/governancelist.cpp (5)

48-50: LGTM: UniValue API modernization for better consistency.

The change from find_value(prop_data, "name") to prop_data.find_value("name") correctly updates to the new member function API, improving code clarity and consistency.

52-54: LGTM: Enhanced type safety with templated integer extraction.

The changes correctly modernize the UniValue API by:

Replacing find_value(prop_data, "start_epoch") with prop_data.find_value("start_epoch")

Replacing get_int64() with getInt<int64_t>() for better type safety and explicit type specification

56-58: LGTM: Consistent API modernization pattern.

Same beneficial modernization as the previous segment - member function call and templated type-safe integer extraction for the "end_epoch" field.

60-62: LGTM: Consistent find_value modernization.

The change from global find_value() to member function call maintains consistency with the API modernization pattern.

64-66: LGTM: Final find_value modernization in the constructor.

Completes the consistent modernization pattern for the "url" field extraction.

src/net_types.cpp (2)

15-17: LGTM: Type-safe UniValue integer extraction.

The changes correctly modernize the UniValue API by replacing:

get_int() with getInt<int>() for nVersion

get_int64() with getInt<int64_t>() for nCreateTime and nBanUntil

This provides better type safety with explicit type specification while maintaining identical functionality.

61-61: LGTM: Consistent API modernization.

The change from get_int() to getInt<int>() for version extraction maintains consistency with the broader UniValue API modernization pattern.

src/coinjoin/options.cpp (1)

81-87: LGTM: Thread-safe atomic member access.

The changes correctly use .load() method for accessing atomic member variables, ensuring thread-safe reads of the CoinJoin configuration options. This is the proper way to access atomic variables in concurrent contexts while maintaining the same JSON output structure.

src/node/interfaces.cpp (1)

701-701: LGTM! UniValue API modernization applied correctly.

The replacement of get_int() with the templated getInt<int>() method aligns with the UniValue API modernization effort while maintaining identical functionality for RPC error code extraction.

src/governance/classes.cpp (1)

91-91: LGTM! UniValue API modernization applied correctly.

The replacement of get_int() calls with templated getInt<int>() methods correctly modernizes the UniValue API usage for parsing governance object type and event block height while maintaining identical functionality.

Also applies to: 96-96

src/Makefile.test.include (1)

408-408: LGTM! Correctly removes obsolete test configuration.

The removal of univalue/test/no_nul from the test list aligns with the broader UniValue subtree cleanup while preserving the other UniValue tests (object and unitester).

src/rpc/rawtransaction_util.cpp (1)

42-42: LGTM! Comprehensive UniValue API modernization applied correctly.

All changes correctly modernize the UniValue API usage:

Replaced deprecated get_int() and get_int64() with type-safe templated getInt<T>() methods

Replaced global find_value() function calls with member method calls

Functionality and error handling remain identical while improving type safety

Also applies to: 54-54, 57-57, 69-69, 71-71, 167-167, 188-188, 201-201

src/univalue/include/univalue_utffilter.h (1)

4-5: Documentation and header guard improvements look good.

The changes improve code documentation and align the header guard with Dash Core conventions using the BITCOIN_ prefix. The enhanced comments about UTF-8 filtering and RFC4627 surrogate pair handling improve code clarity without affecting functionality.

Note: These changes are appropriate given that UniValue is being integrated into the main codebase and is no longer treated as a vendored subtree dependency.

Also applies to: 9-12, 51-51, 63-63, 66-66, 86-97, 119-119

src/util/system.cpp (1)

629-629: LGTM: Correctly modernizes UniValue API usage.

The change from value.get_int64() to value.getInt<int64_t>() appropriately updates to the new templated API, improving type safety while maintaining identical functionality.

src/httprpc.cpp (2)

119-119: LGTM: Proper UniValue API modernization.

The change from find_value(objError, "code").get_int() to objError.find_value("code").getInt<int>() correctly updates to the modern member function approach and templated integer getter, improving both API consistency and type safety.

256-256: LGTM: Correctly updates to member function API.

The change from find_value(request, "method").get_str() to request.find_value("method").get_str() appropriately modernizes the key lookup to use the member function approach, improving API consistency.

src/evo/core_write.cpp (1)

32-35: Minor: drop implicit widening on nVersion

nVersion here is a plain uint16_t; UniValue already has a templated pushKV that handles any integral type, so the direct pass is fine.
If you prefer symmetry with other enum conversions, you can still wrap in ToUnderlying, but this is purely stylistic.

src/rpc/request.cpp (4)

149-149: LGTM: Correct API modernization.

The change from get_int() to getInt<int>() improves type safety by explicitly specifying the expected integer type.

166-166: LGTM: Correct UniValue API update.

The change from global find_value() to member function find_value() aligns with the modernized UniValue API.

169-169: LGTM: Consistent API modernization.

The update to use the member function find_value() is consistent with the broader UniValue API modernization effort.

184-184: LGTM: Proper API migration.

The change from global find_value() to member function maintains the same functionality while using the updated UniValue API.

src/rpc/net.cpp (7)

69-69: LGTM: Simplified return statement.

Removing the explicit cast to int is correct since GetNodeCount() already returns an int.

453-453: LGTM: Type-safe API update.

The change to getInt<int64_t>() is correct for NodeId, which is a 64-bit integer type.

687-692: LGTM: Consistent removal of unnecessary casts.

Removing the explicit int casts is correct since GetNodeCount() already returns the appropriate integer type.

775-775: LGTM: Appropriate type specification.

Using getInt<int64_t>() for ban time is correct as it needs to handle 64-bit time values.

960-960: LGTM: Correct integer type usage.

Using getInt<int>() for the count parameter is appropriate for this use case.

1014-1014: LGTM: Appropriate type for port number.

Using getInt<int>() for the port parameter is correct as port numbers fit within the int range.

1058-1058: LGTM: Correct type for peer ID.

Using getInt<int>() for peer_id is appropriate as NodeId is typically handled as an int in this context.

src/rpc/util.cpp (7)

64-64: LGTM: Correct API migration.

The change to use member function find_value() aligns with the modernized UniValue API.

111-111: LGTM: Consistent API update.

Using the member function find_value() is the correct approach for the updated UniValue API.

124-124: LGTM: Proper API modernization.

The update to member function find_value() maintains functionality while using the modernized API.

151-151: LGTM: Type-safe integer extraction.

The change to getInt<int>() improves type safety for boolean value parsing.

325-325: LGTM: Appropriate type specification.

Using getInt<int>() for confirmation target is correct as these values fit within the int range.

939-943: LGTM: Correct type usage for ranges.

Using getInt<int64_t>() for range values is appropriate as ranges can potentially be large 64-bit values.

1012-1015: LGTM: Consistent API updates.

The changes to use member function find_value() are consistent with the UniValue API modernization throughout the codebase.

src/rpc/blockchain.cpp (2)

110-112: Modernised UniValue accessor – looks good

Replacing param.get_int() with the type-safe param.getInt<int>() removes the implicit narrowing cast and uses the new UniValue API. 👍

2464-2465: Atomic read fixed – good change

Using g_scan_progress.load() instead of relying on implicit conversion avoids the deprecated atomic-to-int cast and eliminates the need for the previous GCC -Wdangling-reference suppression.

src/univalue/test/unitester.cpp (4)

5-9: LGTM! Header consolidation looks good.

The cleanup of redundant headers and consolidation to just include univalue.h is appropriate for the test file.

152-157: Good addition of edge case test.

The no_nul_test() function appropriately tests UniValue's ability to parse JSON substrings from buffers with surrounding data, which is an important edge case for the read() method with explicit length.

161-162: Nice modernization to range-based for loop.

Good use of modern C++ with the range-based for loop, which is cleaner and safer than the previous index-based approach.

166-168: Test execution and return value changes look good.

The addition of no_nul_test() to the test suite and the simplified return statement are appropriate given that test failures are handled via assertions.

src/univalue/lib/univalue_get.cpp (1)

6-17: Good modernization of C headers to C++ style.

The conversion from C-style headers to their C++ equivalents (e.g., <stdint.h> to <cstdint>) follows C++ best practices.

src/governance/governance.cpp (2)

662-663: Correct usage of modernized UniValue API.

The migration from get_int64() to the templated getInt<int64_t>() method is consistent with the UniValue API modernization.

1507-1512: Good removal of unnecessary casts.

Removing the explicit (int) casts when passing size() values to pushKV is an improvement, as it avoids potential truncation issues and relies on the updated UniValue API's ability to handle size_t values directly.

src/wallet/rpc/backup.cpp (4)

1044-1047: hdaccounts field addition looks good

Exposing the HD account count in the resulting JSON object improves tooling-side introspection without affecting existing consumers. No issues spotted.

1089-1093: No concerns with the new “keys” metadata

The added keys entry accurately represents the exported key count and uses an already-instantiated container (vKeyBirth). Implementation is correct.

1460-1464: Type-safe timestamp extraction LGTM

Switching to getInt<int64_t>() keeps the full 64-bit range and aligns with the new UniValue API. ✅

1701-1706: Minor: template argument can match variable type

next_index is int64_t, so using the same width is perfect.
If you prefer brevity, getInt<int64_t>() can be shortened to getInt<int64_t>() looks fine; nothing further.

src/wallet/test/wallet_tests.cpp (3)

922-930: LGTM! UniValue API modernization correctly applied.

The changes properly replace the free function find_value(response, "field") with the member function response.find_value("field") calls. The test logic remains unchanged and the fields being tested match the expected return values from the getaddressinfo RPC handler.

950-950: LGTM! API modernization applied consistently.

The change correctly updates the address extraction to use the member function response.get_obj().find_value("address") instead of the free function find_value(response.get_obj(), "address").

957-967: LGTM! UniValue API modernization completed correctly.

The changes properly:

Replace free function calls with member function calls (response.find_value("field"))

Update integer extraction to use the type-safe templated method getInt<int>() instead of get_int()

Maintain identical test logic while using the modernized API

The type-safe getInt<int>() method is a significant improvement over the old get_int() approach.
src/wallet/rpc/wallet.cpp (1)

889-890: Guard against out-of-range wallet version numbers

getInt<int>() limits the accepted range to [-2^31, 2^31-1]. Although current wallet versions are far below that, the parameter is conceptually an unsigned 32-bit field. Consider parsing into a wider signed type and validating explicitly to future-proof the RPC:
-    int version = 0;
+    int64_t version = 0;
 ...
-        version = request.params[0].getInt<int>();
+        RPCTypeCheckArgument(request.params[0], UniValue::VNUM);
+        version = request.params[0].getInt<int64_t>();
+        if (version < 0 || version > std::numeric_limits<int>::max()) {
+            throw JSONRPCError(RPC_INVALID_PARAMETER, "Version out of range");
+        }
src/wallet/rpc/transactions.cpp (4)

76-76: LGTM: UniValue API modernization

The replacement of get_int() with getInt<int>() is consistent with the broader UniValue library refactor described in the PR. The functionality remains unchanged while using the new templated interface.

509-512: LGTM: Consistent UniValue API updates

Both changes correctly modernize the integer parameter extraction using getInt<int>() instead of the deprecated get_int(). The functionality is preserved while adopting the new templated interface.

635-635: LGTM: UniValue API consistency

The change maintains the same functionality while using the modernized getInt<int>() method for extracting the target_confirms parameter.

888-895: LGTM: Proper height parameter extraction

Both changes correctly update the block height parameter extraction to use getInt<int>() instead of the deprecated get_int(), maintaining the same functionality with the modernized UniValue API.

src/rpc/governance.cpp (4)

911-911: LGTM: Masternode collateral index extraction update

The change correctly modernizes the extraction of the masternode collateral transaction index using getInt<int>() instead of the deprecated get_int().

942-942: LGTM: Proper 64-bit timestamp extraction

The change correctly updates the vote time parameter extraction to use getInt<int64_t>() instead of get_int64(), maintaining the 64-bit integer type for timestamp handling.

1021-1021: LGTM: Simplified integer handling

The removal of the explicit (int) cast is appropriate as the modernized UniValue API handles integer conversion more seamlessly. The functionality remains unchanged.

1045-1045: LGTM: Block height parameter extraction update

The change correctly modernizes the block height extraction using getInt<int>() instead of the deprecated get_int().

src/test/rpc_tests.cpp (11)

83-83: LGTM: Updated to use member function API.

The change from the global find_value function to the member function is consistent with the UniValue API modernization.

142-144: LGTM: Updated to use templated integer getters.

The transition from get_int() to getInt<int>() follows the new type-safe templated API pattern.

159-172: LGTM: Consistent API modernization.

All changes correctly switch from the global find_value function to the member function API.

190-192: LGTM: Consistent member function usage.

The changes correctly use the member find_value function for accessing boolean fields.

255-259: LGTM: Updated for exception-based error handling.

The function signature change to noexcept and removal of the setNumStr return value check is consistent with the UniValue API modernization where setters now throw exceptions instead of returning boolean status.

299-302: LGTM: Enhanced test coverage for boolean values.

The additional test cases for boolean values improve coverage of JSON parsing functionality.

315-319: LGTM: Comprehensive invalid JSON key validation.

The additional test cases properly validate that non-string object keys are rejected, ensuring robust JSON parsing error handling.

335-411: LGTM: Consistent API modernization in ban tests.

All changes properly switch to the member function API and use the templated integer getters where appropriate.

421-436: LGTM: Consistent templated integer getter usage.

The transition to getInt<int>() maintains functionality while using the modernized type-safe API.

558-597: LGTM: Consistent API modernization in BLS tests.

All BLS test cases correctly use the member find_value function, maintaining test functionality while adopting the modernized API.

590-590: Static analysis false positive: Test cryptographic material.

The flagged "API key" is actually a hardcoded BLS secret key used for deterministic cryptographic testing. This is standard practice in test files to ensure reproducible results and is not a security concern.

src/qt/rpcconsole.cpp (2)

264-264: LGTM: Updated to use member function API.

The change from the global find_value function to the member function is consistent with the UniValue API modernization while preserving the command parsing functionality.

463-464: LGTM: Consistent API modernization in error handling.

Both changes correctly update to the member function API, with the error code extraction also adopting the type-safe templated integer getter pattern.

src/rpc/quorums.cpp (6)

167-167: LGTM: Modernization of UniValue API usage

The removal of the explicit (int32_t) cast when pushing num_valid_members to the UniValue object is correct. UniValue can handle size_t values directly, making the explicit cast unnecessary.

214-214: LGTM: Improved type safety with explicit cast

The change from implicit boolean conversion to static_cast<bool>() improves code clarity and type safety while maintaining the same functionality.

919-919: LGTM: Removal of unnecessary cast

The explicit cast when pushing status.sessions.size() to UniValue is unnecessary as UniValue can handle size_t values directly. This change simplifies the code while maintaining the same functionality.

1000-1000: LGTM: Modernized UniValue API usage

The change from the deprecated get_int() method to the templated getInt<int>() method is part of the broader UniValue API modernization effort. This improves type safety and follows the new API conventions.

1066-1066: LGTM: Modernized UniValue API usage

The change from the deprecated get_int() method to the templated getInt<int>() method is consistent with the UniValue API modernization. This change improves type safety and follows the new API conventions.

1121-1121: LGTM: Modernized UniValue API usage

The change from the deprecated get_int() method to the templated getInt<int>() method completes the UniValue API modernization in this function. This change improves type safety and consistency with the updated API.

src/rpc/mining.cpp (8)

123-123: LGTM: Modernized UniValue parameter extraction

The change from deprecated get_int() to the templated getInt<int>() method improves type safety and follows the modernized UniValue API conventions.

235-236: LGTM: Consistent use of templated getInt method

Both parameter extractions now use the templated getInt<int>() method instead of the deprecated get_int(), improving type safety and API consistency. The uint64_t cast for max_tries is appropriate given the variable's type.

274-275: LGTM: Modernized parameter extraction

The changes from deprecated get_int() to templated getInt<int>() method are consistent with the UniValue API modernization. The uint64_t cast for max_tries is appropriate for the variable's type.

506-506: LGTM: Updated to use templated getInt method

The change from deprecated get_int64() to the templated getInt<int64_t>() method improves type safety and aligns with the modernized UniValue API.

671-671: LGTM: Transition to member find_value method

The change from the global find_value() function to the member find_value() method on the oparam UniValue object is part of the UniValue API modernization effort and improves code consistency.

680-680: LGTM: Consistent use of member find_value method

The change to use the member find_value() method instead of the global function continues the consistent modernization of UniValue API usage throughout this function.

684-684: LGTM: Modernized UniValue field lookup

The change to use the member find_value() method instead of the global function maintains consistency with the UniValue API modernization pattern used throughout the codebase.

714-714: LGTM: Completed UniValue API modernization

The final change to use the member find_value() method completes the consistent modernization of UniValue API usage in this function, improving code consistency and following the updated API conventions.

src/bitcoin-cli.cpp (8)

486-486: API modernization looks correct.

The change from get_int() to getInt<int>() follows the new templated UniValue API pattern and maintains identical functionality.

507-516: Systematic API modernization is correct.

All changes from get_int()/get_int64() to getInt<int>()/getInt<int64_t>() are properly typed and maintain identical functionality while improving type safety.

537-537: API modernization is consistent.

The change to getInt<int>() maintains identical functionality for protocol version extraction.

626-626: Local address extraction updates are correct.

Both getInt<int>() calls for port and score extraction follow the proper API modernization pattern.

879-880: Error handling API updates are correct.

The changes from global find_value() to member find_value() and from get_int() to getInt<int>() maintain identical functionality while following the new UniValue API patterns.

907-908: Error parsing API modernization is systematic.

All changes consistently update to the new UniValue API: find_value() becomes a member method and get_int() becomes getInt<int>(), maintaining identical error handling functionality.

Also applies to: 915-915, 921-921

934-935: Wallet balance extraction updates are consistent.

The systematic change from global find_value() to member find_value() maintains identical functionality for wallet balance retrieval.

Also applies to: 942-942

978-978: Final API modernization changes are consistent.

All remaining changes from global find_value() to member find_value() across different functions (ParseGetInfoResult, CommandLineRPC) maintain identical functionality while following the new UniValue API pattern.

Also applies to: 1194-1194, 1196-1196, 1218-1219

src/rpc/node.cpp (11)

227-227: Spork value extraction API update is correct.

The change from get_int64() to getInt<int64_t>() follows the new templated UniValue API pattern and maintains identical functionality for spork value extraction.

264-264: Mock time parameter extraction is correctly updated.

The change to getInt<int64_t>() maintains identical functionality for timestamp extraction with improved type safety.

299-299: Node ID extraction follows the API modernization pattern.

The getInt<int64_t>() change maintains identical functionality for node ID parameter extraction.

360-360: Address parameter extraction API update is correct.

The change from global find_value() to member find_value() maintains identical functionality for extracting the addresses array from parameters.

438-438: Integer cast removals are appropriate.

Removing explicit (int) casts when pushing transaction indices to UniValue is correct - UniValue can handle the underlying integer types directly, making the code cleaner while maintaining identical functionality.

Also applies to: 443-443

512-512: Output index cast removal is appropriate.

Removing the explicit (int) cast when pushing the output index to UniValue maintains identical functionality while making the code cleaner.

554-555: Block height parameter extraction updates are systematic.

The changes from global find_value() to member find_value() and from get_int() to getInt<int>() maintain identical functionality for start/end block height parameter extraction.

Also applies to: 561-562

599-600: Index cast removals are consistent.

Removing explicit (int) casts for transaction and block indices when pushing to UniValue is appropriate and maintains identical functionality.

718-719: Transaction ID query parameter extraction follows the same pattern.

The API modernization changes are consistent with other functions - find_value() becomes a member method and get_int() becomes getInt<int>(), maintaining identical functionality.

Also applies to: 721-722

792-793: Spent info parameter extraction is consistently updated.

The API modernization changes maintain identical functionality for extracting txid and index parameters while following the new UniValue patterns.

Also applies to: 800-800

838-838: Scheduler delta time extraction completes the API modernization.

The change to getInt<int64_t>() maintains identical functionality for scheduler delta time parameter extraction, completing the systematic API updates in this file.

src/rpc/client.cpp (1)

8-8: LGTM! Excellent modernization to use std::string_view

The conversion to std::string_view throughout this file reduces unnecessary string copies and aligns with the modernized UniValue API. The changes are consistent and correctly implemented.

Also applies to: 12-13, 268-277, 293-298, 305-306, 317-325

src/univalue/test/object.cpp (1)

1-442: Changes are part of the univalue backport.

These test modernizations are part of the upstream Bitcoin Core changes being backported. The updates properly reflect the new UniValue API with exception-based error handling and templated getters.

src/univalue/lib/univalue.cpp (1)

1-234: Implementation updates align with the API modernization.

The conversion from boolean returns to exception-based error handling is properly implemented throughout. The member function conversion of find_value is consistent with the header changes.

src/univalue/include/univalue.h (1)

1-199: Header modernization completes the UniValue API update.

The unified templated constructor and exception-based error handling provide a cleaner, more type-safe API. The use of C++17 features like std::string_view and std::from_chars improves efficiency. The BITCOIN_ header guard prefix is correct per Dash Core conventions.

coderabbitai · 2025-07-23T09:51:16Z

src/evo/core_write.cpp

 [[nodiscard]] UniValue CCbTx::ToJson() const
 {
    UniValue ret(UniValue::VOBJ);
-    ret.pushKV("version", (int)nVersion);
+    ret.pushKV("version", ToUnderlying(nVersion));
    ret.pushKV("height", nHeight);
    ret.pushKV("merkleRootMNList", merkleRootMNList.ToString());
    if (nVersion >= CCbTx::Version::MERKLE_ROOT_QUORUMS) {
        ret.pushKV("merkleRootQuorums", merkleRootQuorums.ToString());
        if (nVersion >= CCbTx::Version::CLSIG_AND_BALANCE) {
-            ret.pushKV("bestCLHeightDiff", static_cast<int>(bestCLHeightDiff));
+            ret.pushKV("bestCLHeightDiff", bestCLHeightDiff);
            ret.pushKV("bestCLSignature", bestCLSignature.ToString());


⚠️ Potential issue

Consistency: convert enum values with ToUnderlying

nVersion is explicitly converted with ToUnderlying, but bestCLHeightDiff (plain integral) and nReason below are not enums.
However, CProUpRevTx::nReason is an enum class (see protx.h). Passing it directly relies on an implicit conversion that is forbidden for scoped enums on some compilers. Use the same helper for clarity and portability:

- ret.pushKV("reason", nReason); + ret.pushKV("reason", ToUnderlying(nReason));

This mirrors the pattern used for nType and avoids future compile issues.

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

[[nodiscard]] UniValue CCbTx::ToJson() const

{

UniValue ret(UniValue::VOBJ);

ret.pushKV("version", (int)nVersion);

ret.pushKV("version", ToUnderlying(nVersion));

ret.pushKV("height", nHeight);

ret.pushKV("merkleRootMNList", merkleRootMNList.ToString());

if (nVersion >= CCbTx::Version::MERKLE_ROOT_QUORUMS) {

ret.pushKV("merkleRootQuorums", merkleRootQuorums.ToString());

if (nVersion >= CCbTx::Version::CLSIG_AND_BALANCE) {

ret.pushKV("bestCLHeightDiff", static_cast<int>(bestCLHeightDiff));

ret.pushKV("bestCLHeightDiff", bestCLHeightDiff);

ret.pushKV("bestCLSignature", bestCLSignature.ToString());

ret.pushKV("reason", ToUnderlying(nReason));

🤖 Prompt for AI Agents

In src/evo/core_write.cpp around lines 50 to 60, the enum class member nReason in CProUpRevTx is passed directly without using ToUnderlying, which can cause implicit conversion issues on some compilers. To fix this, explicitly convert nReason using ToUnderlying before passing it to pushKV, following the pattern used for nVersion and nType to ensure clarity and portability.

coderabbitai · 2025-07-23T09:51:17Z

src/rpc/blockchain.cpp

    if (!request.params[0].isNull())
-        timeout = request.params[0].get_int();
+        timeout = request.params[0].getInt<int>();



🛠️ Refactor suggestion

Missing sanity-check for negative timeouts

timeout = request.params[...].getInt<int>(); accepts negative values, which are then forwarded to std::chrono::milliseconds(timeout).
A negative duration is legal, but causes wait_for() to return immediately – not what callers typically expect.

- timeout = request.params[i].getInt<int>(); + timeout = request.params[i].getInt<int>(); + if (timeout < 0) { + throw JSONRPCError(RPC_INVALID_PARAMETER, "Timeout must be non-negative"); + }

Also applies to: 374-376, 419-423

🤖 Prompt for AI Agents

In src/rpc/blockchain.cpp around lines 328 to 330, the code assigns a potentially negative integer from request.params[0] to timeout without validation, which can cause std::chrono::milliseconds(timeout) to create a negative duration leading to immediate return from wait_for(). To fix this, add a sanity check after retrieving the timeout value to ensure it is non-negative, and if negative, either set it to zero or return an error. Apply the same validation logic to the similar code blocks at lines 374-376 and 419-423.

coderabbitai · 2025-07-23T09:51:17Z

src/rpc/blockchain.cpp

+    unsigned int high = request.params[0].getInt<int>();
+    unsigned int low = request.params[1].getInt<int>();
    std::vector<uint256> blockHashes;


🛠️ Refactor suggestion

Signed-to-unsigned cast can silently wrap

Both high and low are declared as unsigned int, but the source value is an int returned by getInt<int>().
Passing a negative timestamp would wrap to a huge positive value without error.

Consider:

-unsigned int high = request.params[0].getInt<int>(); -unsigned int low = request.params[1].getInt<int>(); +const int high_in = request.params[0].getInt<int>(); +const int low_in = request.params[1].getInt<int>(); +if (high_in < 0 || low_in < 0) { + throw JSONRPCError(RPC_INVALID_PARAMETER, "Timestamp must be non-negative"); +} +const unsigned int high = static_cast<unsigned int>(high_in); +const unsigned int low = static_cast<unsigned int>(low_in);

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

unsigned int high = request.params[0].getInt<int>();

unsigned int low = request.params[1].getInt<int>();

std::vector<uint256> blockHashes;

const int high_in = request.params[0].getInt<int>();

const int low_in = request.params[1].getInt<int>();

if (high_in < 0 || low_in < 0) {

throw JSONRPCError(RPC_INVALID_PARAMETER, "Timestamp must be non-negative");

}

const unsigned int high = static_cast<unsigned int>(high_in);

const unsigned int low = static_cast<unsigned int>(low_in);

std::vector<uint256> blockHashes;

🤖 Prompt for AI Agents

In src/rpc/blockchain.cpp around lines 546 to 548, the variables high and low are assigned from getInt<int>() but declared as unsigned int, causing silent wrap if negative values are passed. To fix this, change the variable types of high and low to int to match the source type and add validation to check for negative values before using them, returning an error or handling invalid input appropriately.

coderabbitai · 2025-07-23T09:51:17Z

src/rpc/rawtransaction.cpp


    if (!request.params[1].isNull()) {
-        nSpecificCoreHeight = request.params[1].get_int();
+        nSpecificCoreHeight = request.params[1].getInt<int>();
        if (nSpecificCoreHeight.value() < 0 || nSpecificCoreHeight.value() > chainman.ActiveChain().Height()) {
            throw JSONRPCError(RPC_INVALID_PARAMETER, "Block height out of range");
        }


🛠️ Refactor suggestion

Height should be parsed into a wider integral type.

nSpecificCoreHeight is declared as std::optional<int> and initialised with getInt<int>().
Although current chain heights are well below 2 147 483 647, a 32-bit signed limit is needlessly tight and can break if the RPC is ever used against very long test-chains/fuzz-chains.

- nSpecificCoreHeight = request.params[1].getInt<int>(); + nSpecificCoreHeight = request.params[1].getInt<int64_t>(); if (nSpecificCoreHeight.value() < 0 || nSpecificCoreHeight.value() > chainman.ActiveChain().Height()) {

Also upgrade the std::optional<int> to std::optional<int64_t> for consistency.

Committable suggestion skipped: line range outside the PR's diff.

🤖 Prompt for AI Agents

In src/rpc/rawtransaction.cpp around lines 628 to 633, the variable nSpecificCoreHeight is currently declared as std::optional<int> and initialized with getInt<int>(), which uses a 32-bit signed integer. To handle larger block heights safely, change the type of nSpecificCoreHeight to std::optional<int64_t> and initialize it using getInt<int64_t>(). This widens the integral type and ensures consistency for very long test or fuzz chains.

coderabbitai · 2025-07-23T09:51:17Z

src/univalue/include/univalue_escapes.h

+#ifndef BITCOIN_UNIVALUE_INCLUDE_UNIVALUE_ESCAPES_H
+#define BITCOIN_UNIVALUE_INCLUDE_UNIVALUE_ESCAPES_H


⚠️ Potential issue

Violation of coding guidelines: Changes to vendored dependencies are prohibited.

According to the established coding guidelines, files under src/{crc32c,dashbls,gsl,immer,leveldb,minisketch,secp256k1,univalue}/** should not be modified under any circumstances as they are vendored dependencies. This header guard rename violates that restriction.

🤖 Prompt for AI Agents

In src/univalue/include/univalue_escapes.h at lines 1 to 2, the header guard was renamed, which violates the coding guideline prohibiting modifications to vendored dependencies under src/univalue. Revert the header guard rename to its original state to comply with the guidelines and avoid modifying this vendored file.

coderabbitai · 2025-07-23T09:51:17Z

src/wallet/rpc/coins.cpp

+        nMinDepth = request.params[0].getInt<int>();
    }

    int nMaxDepth = 9999999;
    if (!request.params[1].isNull()) {
        RPCTypeCheckArgument(request.params[1], UniValue::VNUM);
-        nMaxDepth = request.params[1].get_int();
+        nMaxDepth = request.params[1].getInt<int>();
    }


⚠️ Potential issue

Reject negative confirmation depths explicitly

nMinDepth and nMaxDepth are accepted as signed integers but later stored into unsigned fields (coinControl.m_min_depth, coinControl.m_max_depth). Supplying a negative value silently wraps to a huge positive number, producing surprising results.

- nMinDepth = request.params[0].getInt<int>(); + nMinDepth = request.params[0].getInt<int>(); + if (nMinDepth < 0) { + throw JSONRPCError(RPC_INVALID_PARAMETER, "minconf cannot be negative"); + }

Apply the same check for nMaxDepth.

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

nMinDepth = request.params[0].getInt<int>();

}

int nMaxDepth = 9999999;

if (!request.params[1].isNull()) {

RPCTypeCheckArgument(request.params[1], UniValue::VNUM);

nMaxDepth = request.params[1].get_int();

nMaxDepth = request.params[1].getInt<int>();

}

int nMinDepth = 1;

if (!request.params[0].isNull()) {

RPCTypeCheckArgument(request.params[0], UniValue::VNUM);

nMinDepth = request.params[0].getInt<int>();

if (nMinDepth < 0) {

throw JSONRPCError(RPC_INVALID_PARAMETER, "minconf cannot be negative");

}

}

int nMaxDepth = 9999999;

if (!request.params[1].isNull()) {

RPCTypeCheckArgument(request.params[1], UniValue::VNUM);

nMaxDepth = request.params[1].getInt<int>();

if (nMaxDepth < 0) {

throw JSONRPCError(RPC_INVALID_PARAMETER, "maxconf cannot be negative");

}

}

🤖 Prompt for AI Agents

In src/wallet/rpc/coins.cpp around lines 571 to 578, both nMinDepth and nMaxDepth are accepted as signed integers but later assigned to unsigned fields, causing negative values to wrap to large positive numbers. To fix this, add explicit checks to reject negative values for nMaxDepth just like for nMinDepth, ensuring that if nMaxDepth is negative, an error is raised or the input is rejected before assignment.

UdjinM6

utACK 05e2091

Replace deprecated get_int() method with getInt() to match updated UniValue API from bitcoin backport dashpay#6775. Fixes compilation error in arm-linux-build CI job.

…#6775, compile error 0b8fe88 chore: resolve logical conflict between dash#6691 and dash#6775 (Kittywhiskers Van Gogh) Pull request description: ## Additional Information [dash#6691](#6691) and [dash#6775](#6775) were merged into `develop` in that order, neither conflicting with the other. [dash#6775](#6775) updated the UniValue subtree before it was unsubtree'd and subsequent improvements were backported. To enable this, a syntax change was required which replaced `get_int()` with `getInt<int>()`, which, the code introduced in [dash#6691](#6691) didn't use as it was merged _before_ [dash#6775](#6775). As it was new code, this was not registered as a merge conflict but this logical conflict caused `develop` to fail ([build](https://github.com/dashpay/dash/actions/runs/16546102266)). This pull request remedies that issue. ## Breaking Changes None expected ## Checklist - [x] I have performed a self-review of my own code - [x] I have commented my code, particularly in hard-to-understand areas **(note: N/A)** - [x] I have added or updated relevant unit/integration/functional/e2e tests - [x] I have made corresponding changes to the documentation **(note: N/A)** - [x] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_ ACKs for top commit: UdjinM6: utACK 0b8fe88 knst: utACK 0b8fe88 Tree-SHA512: 7af4599e38bca5d776766cd8a2acda46d046f5dfe9f9c45586ac1f27fc709bd6ac913709b2c24d133ab57bbf2a6d5cb0630d0e874f62a472e173d61ced2face0

knst

post-utACK, see follow-up in #6793

26c1c34 refactor: shed avoidable casts, follow-up to bitcoin#25611 (Konstantin Akimov) Pull request description: ## Issue being fixed or feature implemented Small follow-up for bitcoin#25611 (merged via #6775) ## What was done? Shed avoidable casts in evo/mnhftx, llmq/debug ## How Has This Been Tested? See CI ## Breaking Changes N/A ## Checklist: - [x] I have performed a self-review of my own code - [ ] I have commented my code, particularly in hard-to-understand areas - [ ] I have added or updated relevant unit/integration/functional/e2e tests - [ ] I have made corresponding changes to the documentation - [x] I have assigned this pull request to a milestone ACKs for top commit: UdjinM6: utACK 26c1c34 kwvg: utACK 26c1c34 Tree-SHA512: 5b33360014ad449d95099bbb961e2cdcd00a9178cd4aac79b5e51367ab42d8a341dec085c753f4e2b7f9b5f8231ad24a4ea5b700d0a60f198f2702dec02d2591

kwvg added 20 commits July 23, 2025 04:26

revert: bitcoin#25464 (Reduce Univalue push_backV peak memory usage i…

1780961

…n listtransactions) reverts: - 001d7ba.

depends: update 'src/univalue' to bitcoin-core/univalue-subtree@a44caf65

f0caaf9

as b1ae6f5

merge bitcoin#25153: Use getInt<T> over get_int/get_int64

b07e550

depends: update 'src/univalue' to bitcoin-core/univalue-subtree@6c19d050

774a8ff

as 88f794f

merge bitcoin#25113: Bump univalue subtree

9db7b12

Fulfilled by 774a8ff

depends: update 'src/univalue' to bitcoin-core/univalue-subtree@de4f73dd

c0c3af9

as b3443ee

merge bitcoin#25249: Bump univalue subtree

6b9e682

Fulfilled by c0c3af9

merge bitcoin#25369: Unsubtree Univalue

1e023e5

revert: revert bitcoin#25464 (Reduce Univalue push_backV peak memory …

d980870

…usage in listtransactions) reverts: - 780961a6152ccb109f9c51bf54dd7209df9b8f6.

partial bitcoin#25551: Throw exception on invalid Univalue pushes ove…

94bbbf1

…r silent ignore excludes: - ccccc17 (impacts code that is SegWit-specific)

merge bitcoin#25617: univalue test cleanups

7802752

merge bitcoin#25611: Avoid brittle, narrowing and verbose integral ty…

32958da

…pe confusions

refactor: shed avoidable casts in Dash-specific UniValue-ret functions

27cffb1

merge bitcoin#25736: Remove unused and confusing set*() return value

6f03a13

merge bitcoin#25714: Avoid std::string copies

41eb3b0

merge bitcoin#26612: pass named argument value as string_view

203a1c1

merge bitcoin#27605: Replace global find_value function with UniValue…

6d81d06

…::find_value method

kwvg added this to the 23 milestone Jul 23, 2025

kwvg added 2 commits July 23, 2025 07:29

build: drop -Wdangling-reference GCC suppression

f00dc78

merge bitcoin#30464: Fix MSVC warning C4101 "unreferenced local varia…

05e2091

…ble"

kwvg force-pushed the univalue_bps branch from 64d0a14 to 05e2091 Compare July 23, 2025 07:29

kwvg marked this pull request as ready for review July 23, 2025 09:42

kwvg requested review from knst, UdjinM6 and PastaPastaPasta July 23, 2025 09:43

coderabbitai bot reviewed Jul 23, 2025

View reviewed changes

UdjinM6 approved these changes Jul 24, 2025

View reviewed changes

This was referenced Jul 24, 2025

perf: using asynchronous worker to validate BLS signatures in quorum commitments #6692

Merged

backport: trivial batch 380 #6779

Merged

backport: 0.25 batch 393 #6782

Merged

PastaPastaPasta merged commit 94f0caa into dashpay:develop Jul 27, 2025
31 of 34 checks passed

kwvg mentioned this pull request Jul 27, 2025

fix: resolve logical conflict between dash#6691 and dash#6775, compile error #6783

Merged

5 tasks

knst mentioned this pull request Jul 31, 2025

refactor: shed avoidable casts, follow-up to bitcoin#25611 #6793

Merged

5 tasks

knst reviewed Jul 31, 2025

View reviewed changes

DashCoreAutoGuix mentioned this pull request Aug 1, 2025

Merge bitcoin/bitcoin#27605: refactor: Replace global find_value function with UniValue::find_value method DashCoreAutoGuix/dash#781

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

backport: merge bitcoin#25153, #25113, #25249, #25369, #25617, #25611, #25736, #25714, #26612, #27605, #30464, partial bitcoin#25551 (univalue backports) #6775

backport: merge bitcoin#25153, #25113, #25249, #25369, #25617, #25611, #25736, #25714, #26612, #27605, #30464, partial bitcoin#25551 (univalue backports) #6775

Uh oh!

kwvg commented Jul 23, 2025 •

edited

Loading

Uh oh!

github-actions bot commented Jul 23, 2025 •

edited

Loading

Uh oh!

coderabbitai bot commented Jul 23, 2025

Chat

Support

CodeRabbit Commands (Invoked using PR comments)

Other keywords and placeholders

CodeRabbit Configuration File (`.coderabbit.yaml`)

Documentation and Community

Uh oh!

coderabbitai bot left a comment

Uh oh!

coderabbitai bot Jul 23, 2025

Uh oh!

coderabbitai bot Jul 23, 2025

Uh oh!

coderabbitai bot Jul 23, 2025

Uh oh!

coderabbitai bot Jul 23, 2025

Uh oh!

coderabbitai bot Jul 23, 2025

Uh oh!

coderabbitai bot Jul 23, 2025

Uh oh!

UdjinM6 left a comment

Uh oh!

Uh oh!

knst left a comment

Uh oh!

Uh oh!

-    unsigned int high = request.params[0].getInt<int>();
-    unsigned int low = request.params[1].getInt<int>();
-    std::vector<uint256> blockHashes;
+    const int high_in = request.params[0].getInt<int>();
+    const int low_in  = request.params[1].getInt<int>();
+    if (high_in < 0 || low_in < 0) {
+        throw JSONRPCError(RPC_INVALID_PARAMETER, "Timestamp must be non-negative");
+    }
+    const unsigned int high = static_cast<unsigned int>(high_in);
+    const unsigned int low  = static_cast<unsigned int>(low_in);
+    std::vector<uint256> blockHashes;

		#ifndef BITCOIN_UNIVALUE_INCLUDE_UNIVALUE_ESCAPES_H
		#define BITCOIN_UNIVALUE_INCLUDE_UNIVALUE_ESCAPES_H

backport: merge bitcoin#25153, #25113, #25249, #25369, #25617, #25611, #25736, #25714, #26612, #27605, #30464, partial bitcoin#25551 (univalue backports) #6775

backport: merge bitcoin#25153, #25113, #25249, #25369, #25617, #25611, #25736, #25714, #26612, #27605, #30464, partial bitcoin#25551 (univalue backports) #6775

Uh oh!

Conversation

kwvg commented Jul 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Motivation

Additional Information

Breaking Changes

Checklist

Uh oh!

github-actions bot commented Jul 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

⚠️ Potential Merge Conflicts Detected

Uh oh!

coderabbitai bot commented Jul 23, 2025

Walkthrough

Estimated code review effort

Chat

Support

CodeRabbit Commands (Invoked using PR comments)

Other keywords and placeholders

CodeRabbit Configuration File (.coderabbit.yaml)

Documentation and Community

Uh oh!

coderabbitai bot left a comment

Choose a reason for hiding this comment

Uh oh!

coderabbitai bot Jul 23, 2025

Choose a reason for hiding this comment

Uh oh!

coderabbitai bot Jul 23, 2025

Choose a reason for hiding this comment

Uh oh!

coderabbitai bot Jul 23, 2025

Choose a reason for hiding this comment

Uh oh!

coderabbitai bot Jul 23, 2025

Choose a reason for hiding this comment

Uh oh!

coderabbitai bot Jul 23, 2025

Choose a reason for hiding this comment

Uh oh!

coderabbitai bot Jul 23, 2025

Choose a reason for hiding this comment

Uh oh!

UdjinM6 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

knst left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

kwvg commented Jul 23, 2025 •

edited

Loading

github-actions bot commented Jul 23, 2025 •

edited

Loading

CodeRabbit Configuration File (`.coderabbit.yaml`)