fix(ui): validate shielded addresses with the correct RPC
The Validate address dialog chose its RPC from the first character of the input, then asked the transparent-only validateaddress for every case. That RPC is Base58-only, so a valid Sapling (z) address came back isvalid=false and was reported invalid. - The input is now classified with the checksum-verified recognizers, and a shielded address is sent to z_validateaddress while a transparent (mining) address keeps validateaddress. - Anything that is not an address - a typo, garbage, or a pasted viewing/spending key - is judged invalid on the spot and never sent to the node, so a key pasted into the field is not leaked to an RPC. - On Lite there is no node to ask, so the dialog shows the checksum verdict alone and hides the "owned by this wallet" row. Tests: validateRpcMethod maps shielded to z_validateaddress, transparent to validateaddress, and a key or empty string to no RPC. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
@@ -12642,6 +12642,13 @@ void testAddressChecksumValidation()
|
||||
EXPECT_FALSE(isTransparentAddress("Up3W7uVYkLxCfH91APxjSpkkGBWJyBrm3tt1bCz64V5fpZK9ef3C"));
|
||||
EXPECT_FALSE(isDragonXAddress("R9NXAVJezHiBnT3ijTpg3JUZre7PxhJWtX")); // flipped checksum char
|
||||
EXPECT_FALSE(isValidRecipientAddress(""));
|
||||
using dragonx::util::validateRpcMethod;
|
||||
EXPECT_EQ(std::string(validateRpcMethod(classifyRecipient(zaddr))), std::string("z_validateaddress"));
|
||||
EXPECT_EQ(std::string(validateRpcMethod(classifyRecipient(p2pkh))), std::string("validateaddress"));
|
||||
EXPECT_EQ(std::string(validateRpcMethod(classifyRecipient(p2sh))), std::string("validateaddress"));
|
||||
EXPECT_TRUE(validateRpcMethod(classifyRecipient("x")) == nullptr);
|
||||
EXPECT_TRUE(validateRpcMethod(classifyRecipient("zivks1qqqsyqcyq5rqwzqfpg9scrgwpugpzysn")) == nullptr); // a key is never an address -> no RPC
|
||||
EXPECT_TRUE(validateRpcMethod(classifyRecipient("")) == nullptr);
|
||||
}
|
||||
|
||||
// Import-key recognition: the client gate must accept every real DragonX key form and reject
|
||||
|
||||
Reference in New Issue
Block a user