# Payjoin Contributor Sync 03/25

Our primary focus this month is releasing payjoin 0.23 and updating the language bindings in preparation for the MIT Bitcoin hackathon.

We also have a special presentation! Artur from Chaincode BOSS will demo his LDK-node payjoin POC at the end of today's meeting.

## Hackathon

MIT Bitcoin Expo is [hosting a hackathon](https://mitbitcoin.devpost.com/) alongside the conference (April 4-6). Alex Li from HRF approached us to organize a Payjoin track with the goal of integrating it in as many wallets as possible.

The plan is to offer individual wallet challenge prizes, sponsored by participating wallets. Each successful integration can claim that wallet's prize.

Dan, Armin, spacebear, Brandon, (anyone else?) will be there in-person to lead implementations. Remote participation is allowed, so anyone can join.

To ensure the success of the hackathon we must ensure that payjoin 0.23 and language bindings are ready and released **before April 4th**.

## 0.23 release

The upcoming release repays a ton of tech debt and contains a series of breaking changes. Yuval is wrapping up some breaking OHTTP changes, after which we should have a viable release candidate.

## Contributor updates

- ohttp changes update from Yuval
- persistence layer update from Armin
- research update from Armin/Yuval

## Language bindings

In order of priority:
- Bring existing bindings up to date and expose opaque error types.
- Write TypeScript bindings
- Write WASM bindings

## Outline for Boltz swap-as-payjoin

https://gist.github.com/DanGould/425bde63ca13da238071a7935bb3ea3f

## Artur LDK-node POC presentation

https://www.youtube.com/watch?v=EvWzThn7ec8

https://github.com/arturgontijo/payjoin-poc

## Meeting notes

- contributor intros:
Armin: started full-time! working on multi-party
Artur: still learning, part of BOSS program
Ben: Also BOSS, in last meeting mentioned that he wanted to help with API stabilization and tech debt. Busy with BOSS work but has been learning a lot and making progress, most recently helping with mutation test coverage and thinking about how to add it to CI.
nacho: from Chile and also BOSS. discovered payjoin a few weeks ago and been learning about it. working on implementing alternative coin selection strategies, also interested in silent payments on payjoin.
nothingmuch: on a mission to bring insights from CoinJoin to PayJoin so we can have a library model as opposed to the privacy-as-a-service model which arguably has failed.
river: also BOSS, turning attention to WASM bindings.
spacebear: tech debt, testing, outreach.

- hackathon:
There are a few options: Liana, Boltz, Bria or Bull Bitcoin exchange integration depending on what people want to work on. A hackerhouse/shared AirBnb could be arranged depending on interest/attendance.
Armin: silent payjoin POC could be achieved in a hackathon timeframe.
River: Boltz integration is basically the end goal of the WASM integration he's working on already.

- nothingmuch is working on two OHTTP breaking changes:
1. in BIP77 there is no real specification of how the relay and the directory communicate in OHTTP, some of it is implied. In reviewing that we discovered an RFC 9540 which specifies an approach to doing that. It's a minor but potentially breaking change on the protocol level because the receiver needs to be aware of this change (not just between relay-directory). This has been merged into both the ohttp-relay and rust-payjoin repositories.
2. when the receiver chooses a directory the sender needs to be aware of which relays are configured for that specific directory. It is statically configured which is an operational burden for those running relays and a choice they must make. The directory could signal that it's a BIP77 gateway and relays configured properly can check for "allowed purposes" to recognize that it's allowed to forward BIP77 requests to the directory. TLS was a blocker but getting that working has moved the PRs to ready-for-review.
Ben: how do we rollout updates without breaking relays?
Dan: the critical thing is getting the client implementations (Bull Bitcoin Mobile and Cake Wallet) up to date, then relays can be notified to update.
nothingmuch: main consideration re: keeping backwards-compatibility is to not consume cognitive resources from developers trying to get familiar with the project.

- Armin is working on persistence abstraction layer:
Persistence project first came about as a need to have a history of payjoin transactions, and evolved to handling resumable sessions.
Goal is to provide an ergonomic interface that tells downstream users that persistence *has* to be implemented.
#552 implements a Persister trait on Sender and Receiver and is at feature-parity with existing payjoin-cli implementation.
#560 is a different approach that forces the implementer's hand with an ephemeral typestate that needs a persistence to proceed with payjoining.
Dan: has there been work on the "payjoin transaction history" side of this?
Armin: #552 sets it up but will require a follow-up. Potentially could make a POC `payjoin-cli history` command.

- multiparty updates:
nothingmuch: we've had three meetings so far where we discussed research papers on wallet clustering. We know about the unnecessary input heuristic - assuming that is perfectly addressed, is it possible to use clustering techniques (especially based on wallet fringerprints) to identify payjoin transactions not from their structure but from their context. If that's the case, what can be down to defned against these techniques?
In two-party payjoin, you trust your counterparty to not doxx you. Multiparty payjoin allows distrust between counterparties, as it doesn't reveal UTXO ownership.
Anonymous CoinJoins with Arbitrary Values or Boltzmann model by Laurent MT - optimize for multiple transaction interpretations.

- language bindings:
In addition to making bindings for new implementations, first and foremost we need to maintain and service our *existing* implementations with Bull Bitcoin Mobile and Cake Wallet.
payjoin-ffi has uniffi as a feature which allows binding to multiple other languages but doesn't currently support Web Assembly.
Mutatiny/Foundation use a ViewController pattern with plain Rust on the backend
BBM used a concept where they used ? API bindings for TS bindings. We need payjoin in the browser where Node will not work.
river: payjoin WASM can be built into payjoin-ffi directly and generate TS directly. WASM limitations: anything using filesystem needs to be done in the JavaScript side so anything that needs to be persisted will have to be exported as JSON and reimported in Rust. BDK-wasm does this: https://github.com/riverKanies/bdk-wasm/blob/464250b38666e5c187821edf33b8588b14c633a1/src/types/changeset.rs#L30

- Dan proposes to conclude this meeting. nothingmuch unreasonably objects and wants it on the record.