Security: signed transfers must use pending_ledger 2-phase commit

[David-code-tang]

Bounty #59 (Pending Transfer Exploits) finding: confirmation bypass.

Issue #59 describes 2-phase commit pending transfers and lists POST /wallet/transfer/signed as the endpoint that should create a pending transfer. Current implementation executes immediate balance/ledger updates, which bypasses the 24h pending window and undermines the intended safety delay.

Fix:

• Change /wallet/transfer/signed to enqueue into pending_ledger (same semantics as admin /wallet/transfer)
• Check available balance = balance - pending_debits to prevent oversubscription
• Record transfer nonce at enqueue time (replay protection)
• Return pending response (pending_id, confirms_at, tx_hash)

Notes:

• This does not change signature verification; it only changes settlement semantics to match the 2-phase commit design.

[Scottcjn]

Review status: nearly ready but still blocked on deployment compatibility.

Current live deployment executes a single script file at /root/rustchain/rustchain_v2_integrated_v2.2.1_rip200.py.
This PR currently imports from node.payout_preflight ..., which fails in that layout.

Please patch to use a compatibility import pattern, e.g. try local import first, then package import fallback:

• from payout_preflight import ...
• fallback from node.payout_preflight import ...

After that lands, I can fast-merge and queue payout for bounty #59.

[Scottcjn]

Review: PR #127 — Payout Preflight (Bounty #59)

Concept: Good approach to pending transfer validation. The core logic (balance check, duplicate detection, amount validation) addresses the bounty requirements.

Issues to Fix

1. Import path breaks production (CRITICAL)

from node.payout_preflight import PayoutPreflight

Production server runs from /root/rustchain/ — there is no node package. This import will crash the server on startup. The file should be imported directly:

from payout_preflight import PayoutPreflight

2. No test evidence against live API
The PR doesn't include any evidence of testing against the actual RustChain API (https://50.28.86.131). The /pending/confirm endpoint has specific field names and behaviors — please verify your validation logic matches the real server responses.

3. Minor: codex/ branch prefix
This appears to be generated via GitHub Copilot Workspace. That's fine, but please verify the code works against the real endpoint before requesting merge.

Verdict

Correct concept, needs the import path fix and live testing. Fix the import and provide test output showing it works against the real API, then this can be merged.

[David-code-tang]

Patched deployment-compat import issue.

• Server now tries local module import first (single-file runtime), with fallback to package layout.
• Added repo-root payout_preflight.py (deployment shim) and updated CLI/tests.

Import pattern used:

try:
    from payout_preflight import validate_wallet_transfer_admin, validate_wallet_transfer_signed
except ImportError:
    from node.payout_preflight import validate_wallet_transfer_admin, validate_wallet_transfer_signed

Commit: 64754b2.

[Scottcjn]

Review: Signed Transfers 2-Phase Commit

The Finding Is Valid

You correctly identified that signed transfers (/wallet/transfer/signed) execute immediately while admin transfers go through pending_ledger with a 24h delay. This IS an inconsistency worth discussing.

However, This May Be Intentional by Design

• Admin transfers use an API key (can be compromised, shared) → 24h delay as safety net
• Signed transfers use Ed25519 cryptographic signatures (private key never leaves the client) → immediate execution is justified because the proof of authorization is stronger

Implementation Problems

1. from node.payout_preflight import ... breaks production — the server runs as a standalone script (python3 rustchain_v2_integrated_v2.2.1_rip200.py), not a Python package. This will crash on startup.

2. Stale diff base — this PR diffs against an old version of the server. The current main branch has additional features that would cause merge conflicts.

3. Stacks PR #126 files — this PR includes identical copies of payout_preflight.py and its tests from PR #126.

4. from_miner column stores RTC addresses — the pending_ledger was designed for miner IDs ("dual-g4-125"), but this PR inserts RTC wallet addresses ("RTCa1b2c3d4..."). Mixing ID formats in the same column creates confusion in the confirm workflow.

What Would Be Needed

If we decide signed transfers SHOULD use pending_ledger:

• Changes must be inline in the main server file (no separate modules)
• Rebase against current main branch
• Integration test against the running server
• Discussion on whether this is actually desired (Ed25519 verification is already strong auth)

[Scottcjn]

Merged and deployed. Follow-up hotfix 170f963 ensures pending_ledger is created on startup (Node2 was missing the table).