Skip to content

wallet CLI send/melt bypass the daemon's wallet ownership — in-process spend outside buyer.lock/money_lock #167

Description

@orveth

Found during the #166 (lazystart) money review. #166 closes the trade-loop spend path — MCP and mobee collect are thin clients over the daemon socket, the daemon is the only trade-path wallet owner, serialized by buyer.lock + its internal money lock.

The residual surface: the wallet-management CLI — mobee wallet send, mobee wallet melt (and wallet reconcile) — still opens the CDK wallet IN-PROCESS for a spend (wallet_cli.rswallet_ops::send_blocking/melt_blockingopen_wallet) and acquires neither buyer.lock nor the daemon money lock. Running one of these while the daemon is live opens a second concurrent handle to the same CDK sqlite — the cross-process window the daemon architecture exists to close, surviving on the manual-management surface. Pre-existing (not introduced by #166, out of its diff and its stated scope).

Fix options, in rough preference order:

  1. Refuse-with-message when a daemon holds the home's buyer.lock ("daemon owns this wallet — use the daemon path or stop it first") — smallest, fail-closed.
  2. Route send/melt through the daemon socket like collect (daemon gains two management RPCs).
  3. Have the CLI take the same locks the daemon takes (turns the daemon into just-another-contender; weakest).

Until one lands, the operator contract is: don't run manual wallet spends while the buyer daemon is up.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions