feat(key-wallet-ffi): expose asset lock transaction builder#600
feat(key-wallet-ffi): expose asset lock transaction builder#600QuantumExplorer merged 5 commits intov0.42-devfrom
Conversation
Adds `wallet_build_and_sign_asset_lock_transaction` FFI function that builds a Core special transaction (type 8) with AssetLockPayload for Core → Platform credit transfers. The function: - Selects UTXOs from the specified BIP44 account - Derives a one-time private key from the asset lock top-up account - Builds credit outputs from the provided scripts and amounts - Signs the transaction using the wallet's private keys - Returns serialized tx bytes, output index, and the one-time key This is the missing piece for end-to-end iOS asset lock flow: build tx → broadcast → wait for IS lock → submit to Platform. Closes #597 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 5 minutes and 25 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughAdds a new exported FFI function Changes
Sequence Diagram(s)sequenceDiagram
participant Client as Mobile App
participant FFI as wallet_build_and_sign_asset_lock_transaction
participant Manager as FFIWalletManager/FFIWallet
participant Builder as TransactionBuilder
participant UTXO as Wallet UTXO Set
participant KeyAcc as AssetLockAddressTopUp
Client->>FFI: call with credit_output_scripts, amounts, fee_per_kb, etc.
FFI->>Manager: validate handles & pointers
FFI->>Builder: construct credit outputs Vec<TxOut>
Builder->>UTXO: select funding UTXOs (BranchAndBound)
Builder->>KeyAcc: derive one-time private key & mark address used
Builder->>Builder: build_asset_lock(credit_outputs) and sign
Builder->>FFI: return tx bytes, tx len, output index, fee, private key
FFI->>Client: return success (true) + outputs or false + error
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related issues
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Warning Review ran into problems🔥 ProblemsTimed out fetching pipeline failures after 30000ms 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 |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## v0.42-dev #600 +/- ##
=============================================
- Coverage 67.24% 67.14% -0.11%
=============================================
Files 318 318
Lines 67018 67250 +232
=============================================
+ Hits 45066 45153 +87
- Misses 21952 22097 +145
|
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
key-wallet-ffi/src/transaction.rs (1)
995-1280: Please add#[cfg(test)]coverage for this new FFI path.A small test matrix here would quickly catch underfunded selection, key reuse when the next index is unavailable, and
output_index_out/credit-output mapping regressions.As per coding guidelines, "Write unit tests for new functionality in Rust code" and "Place unit tests alongside code with
#[cfg(test)]attribute`.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@key-wallet-ffi/src/transaction.rs` around lines 995 - 1280, Add a #[cfg(test)] mod with unit tests for the FFI path implemented by wallet_build_and_sign_asset_lock_transaction: write tests that (1) exercise an underfunded UTXO set to assert coin selection fails and the FFIError is set, (2) simulate the asset_lock_address_topup account having no next address to verify key reuse/handling of get_next_address_index(), and (3) build a successful case verifying fee_out, tx_len_out/tx_bytes_out, output_index_out and that credit_outputs map to the expected transaction outputs and the one-time private key written to private_key_out; use the FFI types (FFIWalletManager, FFIWallet), populate credit_output_scripts/credit_output_script_lens/credit_output_amounts and credit_outputs_count, and assert expected success/failure and side-effects for each scenario.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@key-wallet-ffi/src/transaction.rs`:
- Around line 1172-1196: The derived one-time address index
(asset_lock_account.get_next_address_index()) is only read and never consumed,
so mark the index as used after deriving the key (e.g., call the account's "mark
as used" or "consume/increment" method on asset_lock_account with key_index—if
the API exposes something like mark_address_as_used(key_index) or
increment_next_address_index(), invoke that immediately after deriving
asset_lock_path) so repeated calls return new addresses; also stop hardcoding
output_index_out = 0: when credit_outputs_count > 1 either accept an explicit
output_index parameter or generate/return a distinct one-time key per output
(iterate credit_outputs_count, derive separate addresses/keys and mark each
index used, or compute output_index_out from the mapping between derived
addresses and the requested output) so each credit output is unambiguously tied
to its own one-time key.
---
Nitpick comments:
In `@key-wallet-ffi/src/transaction.rs`:
- Around line 995-1280: Add a #[cfg(test)] mod with unit tests for the FFI path
implemented by wallet_build_and_sign_asset_lock_transaction: write tests that
(1) exercise an underfunded UTXO set to assert coin selection fails and the
FFIError is set, (2) simulate the asset_lock_address_topup account having no
next address to verify key reuse/handling of get_next_address_index(), and (3)
build a successful case verifying fee_out, tx_len_out/tx_bytes_out,
output_index_out and that credit_outputs map to the expected transaction outputs
and the one-time private key written to private_key_out; use the FFI types
(FFIWalletManager, FFIWallet), populate
credit_output_scripts/credit_output_script_lens/credit_output_amounts and
credit_outputs_count, and assert expected success/failure and side-effects for
each scenario.
🪄 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
Run ID: ec4b5a82-644c-4f87-b2ca-955754dad68f
📒 Files selected for processing (1)
key-wallet-ffi/src/transaction.rs
Addresses CodeRabbit review feedback: 1. Mark the derived asset lock address as used after key derivation so repeated calls derive fresh keys instead of reusing the same one. 2. Document that output_index_out = 0 refers to the first credit output in the payload. For multi-output scenarios, the caller should invoke the function once per credit output. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Add wallet_build_and_sign_asset_lock_transaction to FFI_API.md. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@key-wallet-ffi/FFI_API.md`:
- Around line 1287-1289: The documented C signature for
wallet_build_and_sign_asset_lock_transaction uses Rust-specific syntax for
private_key_out; update the signature to use a C-compatible type (e.g., a
pointer to 32 bytes) so FFI consumers can parse it correctly. Locate the
documented function header for wallet_build_and_sign_asset_lock_transaction and
replace the Rust-style private_key_out: *mut [u8; 32] with a C-compatible
declaration such as uint8_t (*)[32] or uint8_t * (with an explanatory note that
it points to 32 bytes) and ensure the rest of the pointer types remain
unchanged.
🪄 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
Run ID: e94a27ac-1e0a-4ce8-aa65-64ef8b51aa17
📒 Files selected for processing (1)
key-wallet-ffi/FFI_API.md
| ```c | ||
| wallet_build_and_sign_asset_lock_transaction(manager: *const FFIWalletManager, wallet: *const FFIWallet, account_index: u32, credit_output_scripts: *const *const u8, credit_output_script_lens: *const usize, credit_output_amounts: *const u64, credit_outputs_count: usize, fee_per_kb: u64, fee_out: *mut u64, tx_bytes_out: *mut *mut u8, tx_len_out: *mut usize, output_index_out: *mut u32, private_key_out: *mut [u8; 32], error: *mut FFIError,) -> bool | ||
| ``` |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify doc signature vs generated C header for wallet_build_and_sign_asset_lock_transaction
rg -n -C2 'wallet_build_and_sign_asset_lock_transaction' key-wallet-ffi/FFI_API.md
fd -e h -i | xargs rg -n -C3 'wallet_build_and_sign_asset_lock_transaction'Repository: dashpay/rust-dashcore
Length of output: 3883
🏁 Script executed:
# View the full function signature in the Rust implementation
sed -n '996,1020p' key-wallet-ffi/src/transaction.rsRepository: dashpay/rust-dashcore
Length of output: 918
🏁 Script executed:
# Search for any .h header files that might contain the C signature
fd -e h | head -20Repository: dashpay/rust-dashcore
Length of output: 47
Use C-compatible type notation in the documented C signature.
The signature is marked as a c code block but uses private_key_out: *mut [u8; 32], which is Rust-specific syntax. In C, a mutable pointer to a 32-byte array should be documented as uint8_t (*)[32] or uint8_t *. Update the documentation to reflect proper C type notation for FFI consumers.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@key-wallet-ffi/FFI_API.md` around lines 1287 - 1289, The documented C
signature for wallet_build_and_sign_asset_lock_transaction uses Rust-specific
syntax for private_key_out; update the signature to use a C-compatible type
(e.g., a pointer to 32 bytes) so FFI consumers can parse it correctly. Locate
the documented function header for wallet_build_and_sign_asset_lock_transaction
and replace the Rust-style private_key_out: *mut [u8; 32] with a C-compatible
declaration such as uint8_t (*)[32] or uint8_t * (with an explanatory note that
it points to 32 bytes) and ensure the rest of the pointer types remain
unchanged.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The asset lock transaction can be funded from different account types: - IdentityRegistration (m/9'/5'/5'/0'/index') - IdentityTopUp (m/9'/5'/5'/1'/reg_index'/index') - IdentityTopUpNotBound (m/9'/5'/5'/1'/index') - IdentityInvitation (m/9'/5'/5'/3'/index') - AssetLockAddressTopUp (m/9'/5'/5'/4'/index') - AssetLockShieldedAddressTopUp (m/9'/5'/5'/5'/index') The caller now specifies which funding type to use via the `funding_type` parameter. For IdentityTopUp, the `identity_index` parameter identifies which identity is being topped up. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Summary
Adds
wallet_build_and_sign_asset_lock_transactionFFI function for building Core special transactions (type 8) withAssetLockPayload. This enables iOS/mobile clients to perform Core → Platform credit transfers.Closes #597
What it does
The new function:
AssetLockAddressTopUpaccountTransactionBuilder::build_asset_lock(credit_outputs)to create the special transactionFFI signature
iOS usage flow
Test plan
cargo check -p key-wallet-fficompiles with no errors or warnings🤖 Generated with Claude Code
Summary by CodeRabbit