Payjoin’s latest releases address a practical problem for collaborative Bitcoin payments: wallet software needs to keep working when a signing operation takes time or a participant disconnects. The project released its payjoin 1.2.0 library on October 2 and its first stable payjoin-cli on October 5. Together, they offer a concrete implementation milestone for a payment method whose usefulness depends heavily on wallet integration. Library release, command-line release.
The significance is in the plumbing. A protocol can describe a private exchange correctly and still be difficult to fit into an application that talks to a separate signer, queries a wallet service or closes midway through a payment.
Two different kinds of waiting
Version 1.2.0 separates receiver checks into two operations: obtaining the information that needs checking, then returning the result. Previously, those steps used synchronous callbacks. The new interface accommodates signing, ownership lookups and broadcast checks that complete asynchronously or run in another process. Existing callback methods remain available, preserving compatibility. The 1.2.0 changes.
That is application-level scheduling. BIP77, also called Payjoin version 2, addresses a different wait: the sender and receiver need not be online simultaneously. Conflating these changes would overstate the October release. The new library makes existing protocol flows easier to integrate; it does not introduce asynchronous Payjoin for the first time. Payjoin’s protocol explanation.
The stable command-line client demonstrates the newer interface. Its release notes describe replaying saved session events from SQLite so a resumed session continues from its previous state. It also caps the size of downloaded Oblivious HTTP key information, limiting one way a malicious directory could return excessive data. CLI release notes.
Why involve the receiver
In a conventional payment, a sender usually supplies all the transaction’s inputs. Analysts can use that pattern to infer that those inputs share an owner. A Payjoin allows the recipient to contribute coins too, undermining that inference. The parties negotiate using partially signed Bitcoin transactions, or PSBTs, before the final transaction is signed and broadcast. BIP78’s motivation and protocol.
For a simplified illustration, suppose Alice pays Bob 0.01 BTC and Bob contributes an existing 0.02 BTC output. Ignoring fees, Bob can receive 0.03 BTC in the resulting transaction. His balance has increased by the intended 0.01 BTC, while some transaction inputs came from him and some from Alice. Treating every input as Alice’s would produce the wrong ownership conclusion.
Fees still require negotiation. Adding inputs adds transaction weight, and BIP78 allows the sender to specify a maximum additional fee contribution. A privacy benefit therefore does not establish that this particular payment costs less than its ordinary alternative. BIP78’s fee rules.
The receiver can stop hosting a server
BIP78’s original arrangement requires an accessible receiver endpoint and a timely response. BIP77 instead uses a directory that stores encrypted messages until the other participant retrieves them. This removes the receiver’s obligation to run a public server. Someone still operates the directory and relay infrastructure. Async Payjoin architecture.
The messages have end-to-end encryption, while Oblivious HTTP separates knowledge of a client’s network address from its request. That separation has a trust boundary: the OHTTP standard calls for separate relay and gateway operators, with the client trusting its relay to withhold identifying information. Protocol architecture, OHTTP privacy assumptions.
This makes the choice of communication infrastructure part of the privacy assessment. Encrypting negotiation messages does not erase the transaction ultimately published to Bitcoin’s ledger.
Compatibility needs a precise label
As reviewed on October 12, BIP77 remains marked Draft in the BIPs repository. That status can coexist with released implementations. Payjoin operates above Bitcoin’s consensus rules, so adoption depends on wallet development rather than a network-wide activation. BIP77 status, project FAQ.
Wallet-level progress is also visible. Wasabi Wallet’s September 14 release, version 2.8.3, added Taproot support for Payjoin and requires Tor to be enabled for Payjoin use. Those are specific capabilities and conditions. That announcement alone does not establish support for BIP77’s asynchronous exchange. Wasabi release notes.
A payment request containing an optional Payjoin parameter can still be paid conventionally by software that ignores it. BIP77 also starts with a signed fallback payment that either party may broadcast. Because the fallback and collaborative transaction spend the same original inputs, only one can confirm. Successful payment therefore does not itself prove that a Payjoin occurred. BIP77 compatibility and fallback rules.
What to watch next
The useful next evidence is wallet-specific: supported sending and receiving flows, restart behavior, clear fallback status and enforced fee limits. The project’s repository also retains a warning that the library has not yet received independent review by Rust and Bitcoin security professionals. A stable version number should be read alongside that qualification. Project README.
October’s releases make integration more practical. Whether that translates into better everyday payment privacy will depend on tested wallet implementations and how clearly they tell users what actually happened.