Uh oh!
There was an error while loading. Please reload this page.
feat(key-wallet): CoinJoin funding account + drain mode for asset-lock builds - #915
Merged
Conversation
…k builds
Asset-lock builders (build_asset_lock / build_asset_lock_with_signer)
previously hardcoded the funding source to standard BIP44 accounts. This
adds:
- AssetLockFundingAccount { Bip44, CoinJoin }: which account family
supplies (and signs) the funding UTXOs. CoinJoin lets mixed coins fund
an asset lock directly, without first sweeping them through a
transparent BIP44 address.
- drain mode: consume every final UTXO of the funding account and
rewrite the single credit output's value to sum(inputs) - fee. The
TransactionBuilder's SelectionStrategy::All path now also rewrites the
asset-lock payload credit output so the payload always mirrors the
on-chain OP_RETURN burn (a mismatch is consensus-invalid), and rejects
a zero-value drain.
- CoinJoin funding is drain-only: partial spends would need CoinJoin
change re-denomination, which the builder does not do; a non-drain
CoinJoin build is rejected with InvalidData.
The key-wallet-ffi build_asset_lock entry point keeps its behavior
(BIP44, non-drain).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>Contributor
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (2)
📝 WalkthroughWalkthroughAsset-lock construction now accepts BIP44 or CoinJoin funding accounts. CoinJoin funding is restricted to drain mode, drain transactions select all inputs, and asset-lock payload values are validated against the drained amount. FFI and tests use the updated API. ChangesAsset-lock funding and drain flow
Estimated code review effort: 4 (Complex) | ~45 minutes Sequence Diagram(s)sequenceDiagram
participant FFI
participant ManagedWalletInfo
participant TransactionBuilder
FFI->>ManagedWalletInfo: build asset-lock transaction
ManagedWalletInfo->>TransactionBuilder: select BIP44 or CoinJoin funding inputs
TransactionBuilder-->>ManagedWalletInfo: assemble drained transaction
ManagedWalletInfo-->>FFI: serialize transaction output
Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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. Comment |
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
key-wallet/src/wallet/managed_wallet_info/asset_lock_builder.rs (1)
271-289: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winDuplicated drain/CoinJoin validation block.
The exact same 19-line validation (
drain && credit_output_fundings.len() != 1andCoinJoin && !drain) is repeated verbatim inbuild_asset_lock(Lines 271-289) andbuild_asset_lock_with_signer(Lines 393-411). Extracting it into a small private helper avoids future drift between the two entry points.♻️ Proposed extraction
+fn validate_drain_funding(+ funding_account: AssetLockFundingAccount,+ credit_output_count: usize,+ drain: bool,+) -> Result<(), AssetLockError> {+ if drain && credit_output_count != 1 {+ return Err(AssetLockError::Builder(BuilderError::InvalidData(+ "drain asset lock requires exactly one credit output".into(),+ )));+ }+ if matches!(funding_account, AssetLockFundingAccount::CoinJoin { .. }) && !drain {+ return Err(AssetLockError::Builder(BuilderError::InvalidData(+ "CoinJoin-funded asset locks support drain mode only".into(),+ )));+ }+ Ok(())+}Then in both
build_asset_lockandbuild_asset_lock_with_signer, replace the duplicated blocks with:- if drain && credit_output_fundings.len() != 1 {- return Err(AssetLockError::Builder(BuilderError::InvalidData(- "drain asset lock requires exactly one credit output".into(),- )));- }- if matches!(funding_account, AssetLockFundingAccount::CoinJoin { .. }) && !drain {- return Err(AssetLockError::Builder(BuilderError::InvalidData(- "CoinJoin-funded asset locks support drain mode only".into(),- )));- }+ validate_drain_funding(funding_account, credit_output_fundings.len(), drain)?;Also applies to: 393-411
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@key-wallet/src/wallet/managed_wallet_info/asset_lock_builder.rs` around lines 271 - 289, Extract the duplicated drain and CoinJoin validation from build_asset_lock and build_asset_lock_with_signer into a small private helper that accepts the relevant funding account, drain flag, and credit_output_fundings, returning the existing AssetLockError on invalid input. Replace both inline validation blocks with calls to this helper, preserving the current validation order and error messages.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@key-wallet/src/wallet/managed_wallet_info/transaction_builder.rs`:
- Around line 353-380: Hoist the drained == 0 validation in the
SelectionStrategy::All path to immediately after calculating drained and before
updating the destination output or entering the special_payload branch. Return
the existing BuilderError::InsufficientFunds error for zero-value drains, then
remove the duplicate check from the AssetLockPayloadType handling while
preserving its credit output update.
---
Nitpick comments:
In `@key-wallet/src/wallet/managed_wallet_info/asset_lock_builder.rs`:
- Around line 271-289: Extract the duplicated drain and CoinJoin validation from
build_asset_lock and build_asset_lock_with_signer into a small private helper
that accepts the relevant funding account, drain flag, and
credit_output_fundings, returning the existing AssetLockError on invalid input.
Replace both inline validation blocks with calls to this helper, preserving the
current validation order and error messages.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: aef4ebcf-7d56-47db-a153-67371ddb5891
📒 Files selected for processing (3)
key-wallet-ffi/src/transaction.rskey-wallet/src/wallet/managed_wallet_info/asset_lock_builder.rskey-wallet/src/wallet/managed_wallet_info/transaction_builder.rs
Uh oh!
There was an error while loading. Please reload this page.
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@## dev #915 +/- ##
==========================================
+ Coverage 74.54% 74.68% +0.13%
==========================================
Files 327 328 +1 Lines 75032 76451 +1419 ==========================================
+ Hits 55936 57099 +1163 - Misses 19096 19352 +256
|
…drain validation - The `drained == 0` rejection now guards every `SelectionStrategy::All` build, not just the asset-lock payload branch, so a plain drain can no longer produce a zero-value output. - Extract the duplicated drain/CoinJoin funding validation from `build_asset_lock` / `build_asset_lock_with_signer` into a shared `validate_drain_funding` helper. - cargo fmt over the new asset-lock builder tests (CI pre-commit failure). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
xdustinface
approved these changes
Jul 27, 2026
Uh oh!
There was an error while loading. Please reload this page.
bfoss765 added a commit
to bfoss765/rust-dashcore
that referenced
this pull request
Aug 1, 2026
Resolves the conflict flagged on PR dashpay#916 against the current `dev` (9cbe4e7). Only one file conflicted: `key-wallet/src/wallet/managed_wallet_info/asset_lock_builder.rs`, in two places, both the same shape. `dev`'s dashpay#915 (CoinJoin funding account + drain mode) refactored both asset-lock builders from a single chained `TransactionBuilder::new()...` expression into a two-step `let mut builder = ...` so it can conditionally apply `set_selection_strategy(SelectionStrategy::All)` for drain mode. This branch had changed the same statement's destructuring to pick up the new third element, the `Option<ReservationToken>`. Resolution takes `dev`'s two-step builder form and moves this branch's three-element destructuring down onto the `let (transaction, fee, ...) = builder` line that consumes it, i.e. both changes are kept: let (transaction, fee, reservation_token) = builder .set_funding(...) .require_final_inputs() .build_signed_reserved(...) .await?; No semantic conflict underneath: `dev` did not touch `managed_account/reservation.rs`, where the owner-tagged reservation logic actually lives, and the owner-guarded release blocks added by b3c216a still sit after the build in both builders, unchanged. `managed_core_funds_account.rs` and `transaction_builder.rs` auto-merged. Validated after the merge: cargo build -p key-wallet -p key-wallet-manager -p dash-spv \ -p key-wallet-ffi -p dashcore -> clean cargo test -p key-wallet --lib -> 603 passed, 0 failed (incl. 23 reservation tests, TOCTOU regression among them) cargo test -p dashcore --lib -> 577 passed, 0 failed cargo test -p key-wallet-manager --lib -> 49 passed, 0 failed cargo test -p dash-spv --lib -> 494 passed, 0 failed cargo clippy -p key-wallet -p dashcore --all-targets -- -D warnings -> exit 0, 0 warnings Note for the platform#4185 re-pin: this branch's own public API (`ReservationToken`, `build_unsigned_reserved`/`build_signed_reserved`, `ManagedCoreFundsAccount::release_reservation_if_owner`, `AssetLockResult::reservation_token`) is unchanged by this merge. However `dev`'s dashpay#915 independently changed `build_asset_lock` / `build_asset_lock_with_signer` to take `AssetLockFundingAccount` instead of a bare `account_index`, plus a new `drain: bool`. That is a `dev`-side break that #4185 will hit on re-pin regardless of this PR. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
The asset-lock builders (
build_asset_lock/build_asset_lock_with_signer) previously hardcoded their funding source to standard BIP44 accounts. This adds:AssetLockFundingAccount { Bip44, CoinJoin }— which account family supplies (and signs) the funding UTXOs. CoinJoin funding lets mixed coins fund an asset lock directly, without first sweeping them through a transparent BIP44 address (which links the mixed UTXOs to a reusable transparent address for an extra hop).Σ inputs − fee. TheTransactionBuilder'sSelectionStrategy::Allpath now also rewrites the asset-lock payload credit output so the payload always mirrors the on-chain OP_RETURN burn (a mismatch is consensus-invalid), and a zero-value drain is rejected withInsufficientFunds.InvalidData.key-wallet-ffi'sbuild_asset_lockentry point keeps its exact behavior (BIP44, non-drain).Why
Consumed by dashpay/platform (
AssetLockFunding::DrainAccountBalance+ ashielded_fund_from_asset_lock_coinjoin_drainFFI) so the dashwallet-ios post-migration "move your mixed coins" flow can offer a Shielded destination that moves the whole CoinJoin balance into the shielded pool in one transaction, with no transparent intermediate hop.Tests
test_drain_coinjoin_asset_lock— all CoinJoin UTXOs consumed, burn =Σ − fee, payload credit mirrors the burn, no change output, inputs signed.test_drain_requires_single_credit_output,test_coinjoin_funding_requires_drain— guard rejections.key-wallet(551) +key-wallet-manager(48) unit suites pass.🤖 Generated with Claude Code
Summary by CodeRabbit