Send payjoin

[DanGould]

Here's an outline of what a payjoin implementation might look like. There are a few dangling pieces but the bulk of the happy path is here.

• [-] display BIP 78 well-known errors in UI and log the rest Errors are only logged but no json error from the receiver is parsed into an error to Display yet. Wait for library to update Supply & parse receiver response errors payjoin/rust-payjoin#110 as in this design users will not be phished by an undisplayed message.
• ensure BDK will sign & finalize an actual payjoin response
• Test success case with mutiny-web UI draft

A mutinynet payjoin receiver is live and funded when you're ready to test this out by pulling a new payjoin bip21 from https://mutiny.payjoin.org:4433/bip21

Note, this version of payjoin depends on rust-bitcoin v0.30.0 to use the new version of bip21 that disables default features for mutiny. So it duplicates that dependency until Mutiny upgrades.

tag #194, but I don't think it closes it. Send is 1/2 of the equation.

[TonyGiorgio]

Awesome! Really appreciate that.

I think from the frontend point of view, it just uses https://github.com/MutinyWallet/bitcoin-waila for parsing the bitcoin URI and giving the result of that mutiny-node.

So I think just exposing this like it is here

mutiny-node/mutiny-core/src/nodemanager.rs

Lines 984 to 996 in bf98cfc

	pub async fn send_to_address(
	&self,
	send_to: Address,
	amount: u64,
	labels: Vec<String>,
	fee_rate: Option<f32>,
	) -> Result<Txid, MutinyError> {
	if !send_to.is_valid_for_network(self.network) {
	return Err(MutinyError::IncorrectNetwork(send_to.network));
	}
	self.wallet.send(send_to, amount, labels, fee_rate).await
	}

&

mutiny-node/mutiny-wasm/src/lib.rs

Lines 216 to 233 in bf98cfc

	pub async fn send_to_address(
	&self,
	destination_address: String,
	amount: u64,
	labels: JsValue, /* Vec<String> */
	fee_rate: Option<f32>,
	) -> Result<String, MutinyJsError> {
	let send_to = Address::from_str(&destination_address)?;
	let labels: Vec<String> = labels
	.into_serde()
	.map_err(|_| MutinyJsError::InvalidArgumentsError)?;
	Ok(self
	.inner
	.node_manager
	.send_to_address(send_to, amount, labels, fee_rate)
	.await?
	.to_string())
	}

[DanGould]

Would the payjoin Uri check be a better fit in mutiny-wasm, then?

        let uri = payjoin::Uri::try_from(uri)
            .expect("Invalid payjoin URI")
            .require_network(self.network)
            .expect("Payjoin network mismatch")
            .check_pj_supported()
            .expect("Payjoin not supported");

[TonyGiorgio]

Would the payjoin Uri check be a better fit in mutiny-wasm, then?

        let uri = payjoin::Uri::try_from(uri)
            .expect("Invalid payjoin URI")
            .require_network(self.network)
            .expect("Payjoin network mismatch")
            .check_pj_supported()
            .expect("Payjoin not supported");

Oh yeah good point, I think that would be good. That way it can just be passed over to the mutiny-core 's pay_payjoin method.

[benthecarman]

Would the payjoin Uri check be a better fit in mutiny-wasm, then?

        let uri = payjoin::Uri::try_from(uri)
            .expect("Invalid payjoin URI")
            .require_network(self.network)
            .expect("Payjoin network mismatch")
            .check_pj_supported()
            .expect("Payjoin not supported");

maybe this should be added to waila

[DanGould]

it would not be too hard to export the payjoin uri bits as a standalone feature if you wanted to depend on it in waila instead of duplicating

[DanGould]

This has been refactored to handle errors, sign in a BDK environment, produce spec-recommended fee contribution, and separate onchain behavior from nodemanager behavior. I'll have to figure out how to hook it up to mutiny-web to proceed with testing.

[DanGould]

I did have to alter payjoin-cli to filter mixed input contribution with the following

let candidate_inputs: HashMap<Amount, OutPoint> = available_inputs
    .iter()
    .filter(|i| i.address.clone().is_some_and(|a| a.assume_checked().address_type() == Some(bitcoin::AddressType::P2tr)))
    .map(|i| (i.amount, OutPoint { txid: i.txid, vout: i.vout }))
    .collect();

But this was an issue with payjoin-cli (payjoin/rust-payjoin#70), not this draft.

[DanGould]

Other than correctness, the design area I'm most interested in review is the surface between web and node. I wonder if web should completely parse the bip21 and pass validated components, or if node should validate all of the inputs, or both. Right now web just passes a raw destination which node parses.

[DanGould]

@benalleng and I fixed the Failed to send issue. We're having expected solid reliability now 😎 This should be ready for a review.

[benthecarman]

Overall this looks good to me, might want to hold off on merging for now. @TonyGiorgio is doing a pretty large refactor in #867 that will effect this.

[benthecarman]

this can be labels: Vec<String> now

[TonyGiorgio]

Overall this looks good to me, might want to hold off on merging for now. @TonyGiorgio is doing a pretty large refactor in #867 that will effect this.

I can work around it, there's not much I think will conflict.

[TonyGiorgio]

Code looks solid! Thank you both for testing this thoroughly and getting it in here. Exciting!