Skip to content

Conversation

@arminsabouri
Copy link
Collaborator

Pull Request Checklist

Please confirm the following before requesting review:

  • A human has reviewed every single line of this code before opening the PR (no auto-generated, unreviewed LLM/robot submissions).
  • I have read CONTRIBUTING.md and rebased my branch to produce hygienic commits.

@coveralls
Copy link
Collaborator

coveralls commented Aug 25, 2025

Pull Request Test Coverage Report for Build 17239269861

Details

  • 144 of 152 (94.74%) changed or added relevant lines in 4 files are covered.
  • 2 unchanged lines in 1 file lost coverage.
  • Overall coverage increased (+0.06%) to 86.217%

Changes Missing Coverage Covered Lines Changed/Added Lines %
payjoin/src/core/receive/mod.rs 100 101 99.01%
payjoin/src/core/receive/v2/mod.rs 6 13 46.15%
Files with Coverage Reduction New Missed Lines %
payjoin/src/core/receive/v2/mod.rs 2 92.62%
Totals Coverage Status
Change from base Build 17161361666: 0.06%
Covered Lines: 7913
Relevant Lines: 9178

💛 - Coveralls

Introduces `core::receive::WantsOutputs` as a common abstraction to
decouple v1 and v2 typestates.
@arminsabouri arminsabouri force-pushed the decouple-wantsoutsputs branch from b0940fb to 9e40b55 Compare August 25, 2025 18:57
payjoin_psbt: wants_outputs.payjoin_psbt,
params: wants_outputs.params,
change_vout: wants_outputs.change_vout,
receiver_inputs: vec![],
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that receiver inputs is the only field that is different between WantsOutputs and WantsInputs. I'd like to spend some time to see if we can consolidate a shared abstraction for the two typestates.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not longer convinced a shared abstraction between WantsOutputs and WantsInputs achieves any stronger typesaftey or simplifies dx. In fact it would complicated matters bc order of operations matter. i.e outputs must be added before inputs. We could come back to this idea of a TransactionConstruction shared abstraction. However, at the present its not mission critical.

Using bip77 nomenclature.
@arminsabouri arminsabouri force-pushed the decouple-wantsoutsputs branch from 9e40b55 to ad8285d Compare August 26, 2025 13:13
@arminsabouri arminsabouri changed the title WIP - decouple wants outputs Decouple wants outputs v1 and v2 typestates Aug 26, 2025
@arminsabouri arminsabouri marked this pull request as ready for review August 26, 2025 13:14
params: Params,
change_vout: usize,
owned_vouts: Vec<usize>,
pub(crate) inner: crate::receive::WantsOutputs,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm curious why we even need an explicit v1::WantsOutputs struct that wraps crate::receive::WantsOutputs. Would we need changes if crate::receive::WantsOutputs (and other core state types) were merely re-exported as part of the v1 module when feature = "v1" ?

Comment on lines +46 to 47
#[cfg(feature = "v1")]
use crate::output_substitution::OutputSubstitution;
Copy link
Contributor

@DanGould DanGould Aug 26, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you want to export this as receive::v1::OutputSubstitution the right place to do that is in /exclusive/mod.rs because everything exported there is re-exported as

#[cfg(feature = "v1")]
pub use exclusive::*;

Then you don't need an additional feature flag

@arminsabouri
Copy link
Collaborator Author

Dan is taking over this work in #998 . Closing

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants