# Payjoin Contributor Sync 6

Rust-bitcoin summit shed a lot of light on our integrations. We've updated to bitcoin 0.32.2, which BDK, LDK, Fedimint and others have agreed to stabilize on for the near future.

I've taken industry feedback into consideration for our focus on [How Payjoin Saves](https://payjoin.org/docs/how-payjoin-saves/). Now we've got more concrete feedback about how payjoin might be even better positioned toward savings as an automated UTXO management tool. I've also modeled the cost savings compared to [the Optech explanation of payment batching](https://bitcoinops.org/en/payment-batching/).

The primary engineering goal is still stabilize Payjoin V2 in both implementation and specification so that we can serve downstream implementations.

## Thanks for getting `payjoin` 0.19.0 and 0.20.0 out!

2 releases since last meeting.

0.19 introduced the fragment params for v2, allowed sweeps, and made backwards compatibility a lot better.

0.20 fixed a potentially funds-stealing bug among other upgrades.

see the [changelog](https://github.com/payjoin/rust-payjoin/blob/master/payjoin/CHANGELOG.md#payjoin-changelog)

## Release Cut-Through API

Draft PR: https://github.com/payjoin/rust-payjoin/pull/332

Added tests for payment forwarding and UTXO consolidation.

Receiver-side fee contributions is an unsolved issue. For example if consolidating many UTXOs the receiver needs to contribute additional fees to the payjoin tx. The current interface doesn't support this and I'm not sure yet how much of a lift it will be to add.

## More OHTTP Relays

> @oleonardolima will weigh in

I think there still a lack of open OHTTP relays in general, not only for Payjoin. It's also probably related with the usage and initial adoption of the technology. Nevertheless, I see `ohttp-relay` project as an easy to use and simple implementation.

It should be easy to use/deploy so Payjoin users can rely on it, deploying one for it's community or personal usage, and overall Bitcoin (e.g. Cashu (CDK), Esplora) and OHTTP ecosystem can also benefit from it.

I created an issue covering some steps on how we could possibly improve it [#37](https://github.com/payjoin/ohttp-relay/issues/37).

**tl;dr:**

- [ ] docs: add initial setup docs with standard `nginx` & `nohup` usage on common cloud infrastructure.
- [ ] feat+docs(docker): add standard minimal `Dockerfile` without Nix dependency, and usage documentation.
- [ ] feat+docs(nix): add Nix Module usage and deployment documentation.
- [ ] feat(installer): add a friendly setup script guiding user through ohttp-relay setup on common VM systems (?).

## Stabilize Payjoin V2

We're stabilizing Payjoin V2.

That job is split into the `rust-payjoin` tasks and the BIP 77 tasks.

### rust-payjoin V2 implementation stabilization (Beta)

[The issue](https://github.com/payjoin/rust-payjoin/issues/216) describes 4 parts:

#### 1. Enable Secp256k1 DHKEM and ChaCha20Poly1305 AEAD in the hpke crate for ohttp

Bitcoin Core doesn't use TLS, but it does use crypto we can borrow for keeping Payjoin V2 messages encrypted. [This `hpke` branch](https://github.com/rozbb/rust-hpke/tree/unstable-k256) supports this AEAD and could be used to create hpke and ohttp implementations with this ciphersuite.

I plan to release similar functionality in a new [`bitcoin-hpke`](https://github.com/payjoin/bitcoin-hpke/) crate and a follow up ohttp crate, since even if the `rust-hpke` crate accepts k256 changes into their main branch, we still want the bitcoin-specific dependencies in our version.

#### 2. Replace our HPKE implementation with the more standard hpke crate's.

Once these crates support secp256k1 DHKEM, we've got to [integrate it with `rust-payjoin`](https://github.com/payjoin/rust-payjoin/pull/227). There's a PR to do this, but it doesn't comply with MSRV.

#### 3. Replace RustCrypto dependencies with those shared in the rust-bitcoin ecosystem, like the secp256k1 libsecp256k1 bindings crate.

We already depend on secp256k1, and it complies with MSRV, so if hpke can use `rust-secp256k1` instead of `k256` as a dependency to the same end, we should be able to get #2 completed. It would be even better to rely on `rust-bitcoin` for ChaChaPoly1305 which @nyonson is [working on here](https://github.com/rust-bitcoin/rust-bitcoin/pull/2960).

#### 4. Decide on a URI encoding for payjoin params pj subdirectory and ohttp

:white_check_mark: fixed in payjoin-0.19.0

#### 5. Compress BIP21 key config

secp256k1 keys are 65 bytes vs the old 32 byte pubkeys for x25519 keys, and we've got static OHTTP KeyConfig parameters (the crypto primitives we're using), so the serialized key can be much smaller in practice https://github.com/payjoin/rust-payjoin/issues/344

## Do Payjoin

Some of our integrations are closer than others and need some TLC to get over the line

### LDK-Node

LDK-Node requests a standard payjoin (session?) identifier they can use to track the state of it in their database. I think the pj URL is an appropriate identifier but making a decision will make their life easier. The issue contains multiple examples of where this problem has been solved in different ways, so we ought to unify them if a single solution is appropriate across all implementations.

[issue](https://github.com/payjoin/rust-payjoin/issues/336)

### [payjoin-ffi](https://github.com/LtbLightning/payjoin-ffi)

LtbLightning has been iterating on our shaky API to get payjoin working in python and flutter. BullBitcoin wants to use flutter bindings for their mobile app.

We should help them update to the latest version as a release with some semblance of stability instead of a git hash, and stabilize the protocol so they can actually release.

### Galoy Bria [PR](https://github.com/GaloyMoney/bria/pull/445)

This Pull request has been underway since January.

Their entire use case is based on transaction cut through saving fees. As soon as we get cut-through in the API we'll work on this.

### Boltz and the [boltz-rust repo](https://github.com/SatoshiPortal/boltz-rust)

Combining [Boltz x Payjoin](https://gist.github.com/DanGould/425bde63ca13da238071a7935bb3ea3f) to optimistically reduce swaps from a 2-transaction protocol to a 1-transaction protocol has been a point of research for well over a year. Async Payjoin stability should allow it to be able to happen now.

BullBitcoin uses these swaps too so it could help them integrate Payjoin on multiple fronts. Having a rust implementation makes it easy for us to experiment with an integration without commiting to JS bindings first. I believe this integration requires cut-through as well

### BitMask

Bitmask quickly implemented Payjoin V1 sending as soon as it was available. However, our key contact @cryptoquick Hunter Beast is still interested in upgrading to V2. BitMask is willing to implement an early version of Payjoin V2.

Originally they had [open source code](https://github.com/diba-io/bitmask-core/) but have since closed it.

## Expressing Batching

[strategy](https://hackmd.io/X5Vq6L4eQAq8cxmyjGiwuA)

Intro article "[How Can Payjoin Save 16% on Transaction Fees?](https://payjoin.org/docs/how-payjoin-saves/) has been published, but can potentially be refined. The savings data ought to be incorporated and we should add concrete transaction examples instead of just leaving the algebraic savings calculation in the article alone.


[plots generated with this python code](https://github.com/payjoin/batch-plot)

Migration of `payjoindevkit.org` materials (blog, docs, tutorials) to `payjoin.org` with 301 permanent redirects STILL needs to happen. I'd like to to change `payjoindevkit.org` to a dev-specific landing page.

- Get V1 docs up. I've got a tutorial written that just needs to be formatted and PRd
- Duplicate some material on [PlanB](https://planb.network/tutorials/others/write-tutorials) for leads
- Collect and [Add testimonial marquee](https://github.com/payjoin/payjoin.org/pull/80) for payjoin.org

Colors should be unified, I think the footer is still the default. payjoindevkit.org has a coherent pallete.