fix: validate bridge base address hex

[hungle123-dev]

/claim #5434
/claim #305

Summary

• Reject non-hex Base addresses in node/bridge_api.py::validate_chain_address_format.
• Add regression coverage for a length-valid 0xZZ... Base address.
• Preserve existing valid Base address and existing prefix/length validation behavior.

Root cause

The Base address validator only checked address.startswith(0x) and len(address) == 42. That allowed strings that are the right length but not valid hexadecimal addresses.

Validation

RED first:

• python -m pytest tests/test_bridge_lock_ledger.py::TestAddressValidation::test_invalid_base_address_non_hex -q failed with assert True is False.

GREEN after fix:

• python -m pytest tests/test_bridge_lock_ledger.py::TestAddressValidation -q -> 8 passed.
• python -m py_compile node\bridge_api.py tests\test_bridge_lock_ledger.py -> passed.
• git diff --check -- node/bridge_api.py tests/test_bridge_lock_ledger.py -> passed.

[kekehanshujun]

Reviewed head e0e089c6a7519ec2c5e626a04aa3c0015ba6bbbf for the node/bridge_api.py Base address format validation.

Validation run from a minimal PR-head extraction:

• $env:PYTHONPATH=.tmp-pr5435-files\node; python -m pytest ".tmp-pr5435-files\tests\test_bridge_lock_ledger.py::TestAddressValidation" -q --confcutdir=.tmp-pr5435-files -> 8 passed
• python -m py_compile .tmp-pr5435-files\node\bridge_api.py .tmp-pr5435-files\node\lock_ledger.py .tmp-pr5435-files\tests\test_bridge_lock_ledger.py -> passed

The validator now rejects 0x + length-valid strings containing non-hex characters while preserving the existing prefix and length checks. I did not find a blocking issue in this change.

[HCIE2054]

LGTM! Thanks for contributing!

[HCIE2054]

LGTM! Thanks for contributing!

[TJCurnutte]

Approved after a focused bridge address-validation pass.

What I checked:

cd /tmp/rustchain-review-pr5435-76484
git diff --check origin/main...HEAD -- node/bridge_api.py tests/test_bridge_lock_ledger.py
python3 -B -m py_compile node/bridge_api.py tests/test_bridge_lock_ledger.py
uv run --no-project --with pytest --with flask python -B -m pytest -q tests/test_bridge_lock_ledger.py --noconftest
PYTHONPATH=node python3 -B - <<'PY'
from bridge_api import validate_chain_address_format
cases = {
    'non_hex': ('base', '0xZZ2d35Cc6634C0532925a3b844Bc9e7595f0bEb0'),
    'short': ('base', '0x1'),
    'valid_mixed': ('base', '0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb0'),
}
for name,args in cases.items():
    print(name, validate_chain_address_format(*args))
PY

Validation result: 42 passed in 2.43s; the runtime probe returned non_hex (False, 'Invalid Base address hex'), short (False, 'Invalid Base address length'), and valid_mixed (True, '').

The change is narrow and lands in the right order: Base addresses still fail fast on missing 0x and bad length, and 42-character values now also reject non-hex payloads before the bridge accepts them. The added regression test covers the non-hex case directly. I do not see a blocker in this PR-scoped review.

[508704820]

Security Review:

Validating bridge base address hex format prevents malformed addresses from being stored in the bridge contract.

Security considerations:

1. Address collision risk - Hex validation alone doesn't prevent address collisions. Two different input formats could normalize to the same address. Ensure canonical form is enforced before storage.
2. Bridge replay attacks - Can a previously valid bridge address be replayed after the real address is updated? Bridge address changes should invalidate pending transactions.
3. Cross-chain address format - Is the hex format specific to RTC addresses, or does it need to support external chain addresses (Ethereum, Solana)? Different chains have different address lengths and formats.
4. Address whitelisting - For critical bridge operations, consider maintaining an allowlist of approved bridge addresses rather than just format validation.

• Xeophon (wallet: RTC9d7caca3039130d3b26d41f7343d8f4ef4592360)

[ZacharyZhang-NY]

Reviewed PR #5435 at head e0e089c.

Validation performed:

• Checked issue #5434. The scoped bug is that validate_chain_address_format("base", address) accepts 42-character 0x addresses containing non-hex characters.
• git fetch origin pull/5435/head:review-pr-5435 --force
• git diff --check origin/main...review-pr-5435 -- node/bridge_api.py tests/test_bridge_lock_ledger.py -> passed.
• python -m py_compile node/bridge_api.py tests/test_bridge_lock_ledger.py on an extracted PR-head tree -> passed.
• PYTHONPATH=/node python -m pytest tests/test_bridge_lock_ledger.py::TestAddressValidation -q --confcutdir= -> 8 passed.
• Ran a focused runtime probe for Base address validation: a mixed-case valid hex address returned (True, ""), 0xZZ... returned (False, "Invalid Base address hex"), a missing 0x prefix returned the existing prefix error, and a short address returned the existing length error.

The patch keeps the existing Base prefix and length checks intact, adds the missing hex-character validation, and adds direct regression coverage for the issue. Approving.

[BossChaos]

Code Review — Bounty #73

PR: fix: validate bridge base address hex by @hungle123-dev
Files changed: 2 (+9/-0)

• ✅ Bug fix or input validation
• ✅ Input validation present

Summary

This is a bug fix PR. Changes appear consistent with project patterns.

Wallet: 0xdaE5d307339074A24F579dB48e7c639359D94904

Reviewing under Bounty #73 — Code Review Bounty Program

[HCIE2054]

LGTM!

[HCIE2054]

LGTM!

[HCIE2054]

LGTM!

[508704820]

Validate bridge base address hex. Verify: (1) Both 0x-prefixed and raw hex are handled correctly. (2) Invalid addresses are rejected with 400, not 500. (3) Validation consistent with #5437 and #5471. - Xeophon (security review, bridge)

[HCIE2054]

LGTM!

[HCIE2054]

LGTM!

[HCIE2054]

LGTM!

[HCIE2054]

LGTM!