spacebear

I haven't looked into the JoinMarket receiver flow yet. I agree that it would be great to at least try it with PDK on a custom Tor setup and close...

I was able to hook this up by using `socat` like this: ``` $ socat TCP-LISTEN:8888 SOCKS4A:localhost:.onion:80,socksport=9150 $ RUST_LOG=trace cargo run -- send "bitcoin:tb1q7qklxtkpprwrnp4k8v5zd2f9ccqcraaaz7pad7?amount=0.0001&pj=http://localhost:8888" --fee-rate 1 ``` This required a...

I made a successful payjoin tx with the [above patch](https://github.com/JoinMarket-Org/joinmarket-clientserver/pull/1700) in JoinMarket. Signet tx [here](https://mempool.space/signet/tx/e10ca0f3bbcf3b1cabc3e562d7e58db60846587787bcf5f7976b6295abcb7078) (notice the 3 inputs)

This was closed by https://github.com/payjoin/rust-payjoin/pull/281/files which added a proper DB and the option to set a custom DB path as an option.

Thanks @willcl-ark for picking this up! Confirmed this fixes the CHECK_NONFATAL abort when a witness signature is invalid. tACK f57f68ba95fc8778fe2dc755da1e631fe60592c4

@benalleng was there something blocking this PR?

> A follow-up question, where is an appropriate place to actually pad this message to equal the array length of the PADDED_PLAINTEXT_A/B_LENGTH I'm not sure I actually understand the motivation...

I guess the logical place to pad the message is right before `encrypt_message_a/b` are called in the respective `create_x_request` functions.

I don't see why ubuntu-latest runners even need this, since python CI is passing currently? Just removing those entirely seems fine.

I thought about this more: even if our v1 sender implementation does the "right" thing and enforces `pjos=0`, the v2 receiver is still technically not backwards-compatible because we can't guarantee...