tari-project / tari / 39401183523

76%

Build Type

push

github

Committed by web-flow

Commit Message

fix(offline-signing): make multisig deposit and withdraw outputs recoverable by the recipient (#8147)

Description
---

Offline multisig deposits never reached the recipient's wallet. The
offline signer built the recipient output in a way the recipient's
scanner could not recover. This PR fixes the key derivation and adds an
earlier address check.

**Signer (`offline_signing/one_sided_signer.rs`)**
- `build_multisig_output` used the recipient's public **spend** key
where it needed the public **view** key. The commitment mask, the
encrypted-data key and the stealth script key all came from that key
exchange. The recipient's `try_output_key_recovery` uses the view key,
so `scan_outputs_for_multisig` never found these outputs. The deposit
path now uses `public_view_key()`, as the withdraw path and the online
multisig path (`spec_keys`) already did.
- `sign_multisig_transaction` and `sign_multisig_withdraw_transaction`
passed `None` as the custom recovery key to `add_recipient`. When the
memo fee differed from the final fee, which is always the case in the
wallet's deposit flow once there is change,
`update_encrypted_data_and_metadata_sig` re-encrypted the output under
the sender's own view key. Both builders now return their
`DHEncryptedData` key, and it is passed to `add_recipient`.

**Prepare (`offline_signing/offline_signer.rs`,
`wallet/.../transaction_service/service.rs`)**
- `prepare_deposit_multisig_transaction` and
`prepare_withdraw_multisig_transaction` refuse a recipient with no view
key (a single address).
- The wallet's deposit handler checks this before it selects and locks
inputs. Previously such an address only failed at the offline signer,
after the operator had approved.

Motivation and Context
---

A multisig deposit signed offline was mined, but it never showed up in
the recipient's wallet, so the recipient could not use it in the
multisig spend flow. The funds were stuck until recovered by hand.

How Has This Been Tested?
---

- New te... (continued)

Coverage Stats

239 of 243 new or added lines in 4 files covered. (98.35%)

732 existing lines in 25 files now uncovered.

137443 of 179729 relevant lines covered (76.47%)

561410.73 hits per line