This idea first manifest itself in this January mailing list post, inspired by attempts to address the hosting barrier with Tor or application-specific payjoin implementations. Incompatible implementations are the status quo, so payjoin use is limited in practice. The good news is that community and industry show great interest in coming to consensus so that a new version has as wide adoption. The technology to guarantee privacy and usability is now available to do so too.

Adam Gibson and Dave Harding helped define a concrete threat model and proposed better crypto to address it. Symphonicbtc and Christopher Allen proposed encoding specifics to improve user experience to keep payjoin request QR codes small inside the bitcoin URI standard. Apparently, the day after the bounty was announced, Kukks submitted a slick proposal using nostr extending /dev/fd0’s nostr payjoin implementation for both network transport and encryption. Contributors on Twitter, Nostr, and Stacker News and in private all voiced feedback that they want to see change and shared the features they want most.

A way to send messages

To send payjoins we need a way for sender and receiver to communicate to one another. To make it work when one party is offline, we need a box in the middle to store and forward their messages. The original BIP proposes WebTransport, a modern web standard with low latency in mobile environments, and backwards compatible fallback to HTTP. WebSockets could work fine as well.

Popular feedback has been to use nostr. I love nostr for sharing notes. It’s simple, censorship resistant, and has created a cult following. The people I want to talk to share notes there too. Under the hood, Nostr chooses WebSockets, JSON, and requires each message be signed. There are already dozens of free relays anyone can post and listen to. Rijndael summed it up: “nostr is MQTT for web devs,” meaning anyone can publish and subscribe to the messages they’re interested in.

The main argument to use nostr transport is that relays are running for free already so (mistakenly) no payjoin-specific relay has to be run. Kukks’s implementation uses nprofile identifiers in the `pj=`URI parameter to share identities and relays at the same time. I say this is mistaken because as-is, such a solution would not be backwards compatible, and to make it backwards compatible, it would need payjoin-specific components. Without them, payjoin requests using nprofile identities would fail silently in current implementations, leading to even more fragmentation users already complain about. Fragmentation is the problem we’d like to address in the first place. Ammending payjoin v1 instead of introducing v2 closes the door on the opportunity for us to upgrade to PSBTv2 as well.

PSBT version 1 was created to fascilitate cold storage signing and multisig coordination. It was built before interactive protocols were as popular so does not support input and output map mutation. PSBT version 2 does. I see this opportunity to specify a new application protocol to inspire software to upgrade. Cooperative transaction building scales bitcoin by batching better, saving fees as a result, and offering the opportunity to preserve everyone’s privacy with as in payjoin.

One worthwhile possibility is to convince the 10+ extant BIP 78 payjoin implementations to just upgrade in lockstep. They all have a history of collaboration. In my opinion, we need unanimous support to justify such a change, and are better off upgrading to a new payjoin version 2 so we can use PSBTv2 without hiccups.

The bigger issue I see with nostr as transport without payjoin-specific components is that it would rely on nostr cryptosystems, namely NIP 4, which comes with a damning security warning: “This standard does not go anywhere near what is considered the state-of-the-art in encrypted communication between peers, and it leaks metadata in the events, therefore it must not be used for anything you really need to keep secret.”Payjoin messages really need to keep secret. NIP 4 is not viable for payjoin.

Well kept secrets

Payjoin is a technology whose users depend on it for privacy, and that privacy only holds if the messages stay secret. The privacy basis for payjoin transactions is their indistinguishably from many types of other typical transactions and the inability of an outside observer to distinguish which output belongs to a which input, even with knowledge that the transaction you’re looking at is payjoin. If the first message coordinating a payjoin, the Fallback PSBT, were comrpromised, the result would provide no privacy at all. The message it contains both the transfer amount and the inputs belonging to the sender which the Payjoin PSBT would otherwise protect.

The original Serverless Payjoin proposal encrypted the messages using a symmetric key shared in the payjoin request URI for simplicity. Careful consideration of user expectation will reveal that this can lead to an attack. If the relay finds out the URI it would be able to decrypt message contents and also forge messages as the receiver and steal funds through output substitution, replacing the receiver’s output with their own. Bitcoin users understand that leaking addresses in URIs can leak privacy, but don’t expect doing so to put their funds at risk. This attack can be prevented by sharing a receiver public key in the BIP 21 instead of a secret, and transmitting a sender public key inside the first encrypted message.

Diffie-Hellman key exchange before messaging would allow both messages to be protected from a single party key compromise with the cost of an additional round of communication. I suggest Serverless Payjoin foregoes this tradeoff for the sake of convenience, instead relying on per-session asymmetric keys. That way, payjoins can be done in a single round of communication while the only way messages would be exposed were if they were compromised before or during the session as long as they are safely deleted afterward and never reused.

Metadata matters

While Nostr could be used for per-session encryption the same way, a culture of key reuse and copying secrets into web pages has emerged as the way to “log in.” Even Kukks’s proposal accommodates key reuse, which gives me further pause about relying on Nostr standards for message secrecy. Payjoin messages on Nostr would be trivial to identify. A malicious relay could collect messages signed by reused keys and put payjoin participants’ privacy at risk.

Beyond the contents of the messages themselves, a relay having knowledge of IP addresses associated with sender and receiver as well as the timing of candidate payjoin transactions is in a special position to carry out targeted attacks to spoil any privacy benefits. If it can correlate IP address activity with on-chain transactions by timing, it can reveal the underlying transfers that the payjoin would otherwise keep private. Knowing the order of connections could reveal which IP was the sender and which was the receiver. In order to keep payjoin data secure, this metadata must be protected as well as message contents.

Adam Gibson and Matt Corallo have suggested that payjoin messages be padded in order to prevent a relay from correlating them with transactions on chain. I wholeheartedly agree. This simple change protects users at virtually no cost. Whether to use a constant size (based on the maximum size of the encreypted PSBT and parameters) or random padding remains unspecified. I’d love to hear your suggestions here.

Adam noted that timing could be used to correlate IP-related payloads with on-chain activity on bitcoin-dev. He resurfaced Tor as a solution, which I’d like to avoid. BIP 78 Tor receivers do exist, but they’re incompatible with senders who don’t support Tor. In order for a Serverless Payjoin solution to grow, new clients of version 2 should be able to communicate with every other v2 client and not get siloed into the choices of specific clients. And many wallets who’d prioritize privacy to some extent still choose not to use Tor because of the usability hurdles it presents.

A random delay between the sender receiving a transaction and broadcasting it may be the simplest way to break up correlation between the time a payjoin was coordinated and the time it made it into mempools or on chain. Unfortunately this doesn’t keep the relay from linking the IPs to senders and receivers.

A hopeful alternative might be Oblivous HTTP. OHTTP is a relatively new IETF standard that works on the same principles as Tor, but without the complexity of its own decentralized consensus mechanism and the latency symptom of sending requests over a great many hops. Instead, it does the minnimum necessary to separate IP addresses from requests. OHTTP is supported by iOS, Cloudflare, Chromium and Firefox, and has maturing libraries in Rust and Go. In Firefox it is used to separate a user’s IP address from its DNS queries. I have confidence it will become widely available to support our goal of payjoin adoption.

In the context of a relayed payjoin it also makes a lot of sense. The payjoin relay server would have to understand OHTTP as a gateway Resource The receiver allocated buffer on the relay assumes the role of target resource. It could take requests from any OHTTP relay resources which would be operated by entities independent to the payjoin relay, like VPN providers you pay to be independent or non-profit organizations with reputations of being so.

Such an architecture would be a major simplification compared to Tor and provide a similar privacy benefit by keeping the clients’ IP addresses from the payjoin relay, increasing the costs of targeted attacks mentioned earlier by requiring collusion between multiple independent entities. An architecture based on OHTTP could even allow backwards v1 compatibility for senders, but would not provide the same privacy guarantees.

Let’s come to consensus

Serverless Payjoin is meant to lift barriers to adoption and increase real world payjoin by improving compatibility across varied software environments. A successful lift may require payjoin-specific relays, but that’s no news to bitcoin. Every wallet already runs some infrastructure on behalf of themselves or their clients, and one payjoin relay could support many wallets and services. The protocol is being vetted and specified in public, so you’ll be able to self-host too.

Getting encryption and metadata protected is as critical as the transaction structure to maintain privacy. If we can’t get the existing implementations to commit to a timely upgrade, backwards compatibility should be considered necessary to accomodate payjoin v1 senders. We should take this opportunity to leverage PSBTv2. I’m confident in the BIP process to deliver quality software and encourage feedback on the evolving BIP gist. Thanks for your participation, bitcoin privacy is better for it.

Here’s the past month of Payjoin progress recapped. We hit quite a few media features and development milestones. Don’t miss the Payjoin UX Research call tomorrow with the Bitcoin Design Community.

Payjoin Dev Kit is Launched

PDK is finally here to make Payjoin a drop in interactive transaction system for any wallet or service. The release post details the history of development and support as well as a high level roadmap of PDK’s approach to plugging payjoin in everywhere.

PDK on TFTC

Marty Bent got a whiff of PDK and wanted to chat right away. What resulted is an audio FAQ on the current state of Payjoin and Payjoin Dev Kit.

Postr: Payjoin using Nostr

/dev/fd0 Proposed a version of Serveless Payjoin using Nostr to discover one another, handle authentication, and encryption. This is one of the slickest Payjoin proofs of concept I’ve ever seen.

Payjoin V2 Goals Defined

A handful of developers in Prague got the first look at a BIP draft for a new version 2 Payjoin protocol. We came to rough consensus on the goals of such a protocol. It surprised me to hear how much desire there was for a more generic Pay-to-Endpoint standard.

It sounded like the devs in Prague were sick of scanning QR codes that were too dense and want to have the option to push more data between devices for interactive transaction negotiation over the internet beyond payjoin. I like to think near-field communication (NFC) technology will fix this problem, as it has largely replaced swiping magnetic strips for credit cards.

Ignoring the QR problem to focus back on Payjoin specifics we came up with this shortlist of goals: To enable receipt of a Payjoin without hosting a secured public server or losing privacy when using a proxy, to minimize upstream dependencies, To handle errors messaging in a way that could work with multiple underlying transport protocols, and to make the protocol asynchronous.

Getting the community involved to agree on what such a standard will look like is the only way we’re going to be able to deploy it across a range of industry applications.

Subscribe now

BDK-CLI Payjoin Support Drafted

Will Owens has been hard at work integrating Payjoin into BDK (using PDK, of course). The draft has been released and review has already discovered some abstractions to integrate Payjoin into BDK even more easily in the future.

This work also shines a light on Payjoin developer tooling as more developers get their hands on integrations with different requirements but common libraries.

Privacy, Incentives, and Bitcoin as Religion on The Conor Chepnik Podcast

Conor and I jammed out in person to chat. Beyond the usual Payjoin details we cover the Boston Bitcoin Scene, how Bitcoin can be viewed as a Religion, BitDevs’ service as a reliable plug and play Bitcoin Meetup and some of the reasons contributing to Bitcoin is meaninful.

BOB Space’s First Cohort Begins

BOB Space collaboration started in earnest this past month. We’re getting organized and collaborating on infrastructure, design, and development. I am looking forward to working more closely with this team as time goes on. I’m grateful for all of the collaboration that’s already meshing together.

Payjoin UX Research Call Tomorrow

This research will be presented to elicit community feedback in 2 parts:
First I will walk through Payjoin, what it is and why it is important for privacy, Next Yashraj will walk us through Case Study research done in order to understand the Payjoin user experience. The incentives and objectives for both senders & receivers, as well as payjoin UX on both sides will be covered. Hope to see you there.

Please give your feedback by finding me on Nostr or on Twitter by tweeting @bitgould. Bitcoin privacy is being solved thanks in no small part to your help.

Sending love to you & yours,

Dan

Payjoin support and adoption has been growing this spring. May opened up a number of discussions from new contributors for ideas to use payjoin to solve problems other than privacy.

Practical Payjoin Adoption

At the Miami Bitcoin Conference, “A 60yo woman bought a Passport with Payjoin in person” from Foundation Devices. Real world adoption is the whole point, so I’m celebrating this one. Cheers to the Foundation team for their leadership in this direction.

BTCPayServer fixed a payjoin bug for the next release. I’m excited to try it out. Thank you Kukks and Pavlenex. The OG payjoin software continues to evolve.

The Payjoin Dev Kit library payjoin v0.8.0 has been released. Receiver error handling has been overhauled and tested with other independent payjoin compatible software. Wallets who enjoy persistent internet connectivity should reach out to evaluate an integration. It works.

New Advanced Payjoin Uses

You may have seen some of the new ways to use payjoin to reduce fees in in the last post about batching. Friends at Bitcoin Optech picked it up in Newsletter #251. Dave Harding revived Greg Maxwell’s transaction cut-through idea to describe down this kind of cooperative batching. The payjoin protocol handles the accounting authentication that Greg left as an open question in the 2013 bitcointalk post introducing the idea. Thanks to Optech host a twitter space where I was able to add more color on the idea next to @glozow, @actuallyCarlaKC, Severin Bühler, Mike Shmidt, and Murch. Have a listen.

Dusty Daemon, the champion of lightning splicing exclaimed “Payjoins and Splicing are a match made in heaven!” Dusty is funded by OkCoin to pursue splicing. I’m looking forward to exploring this match in more depth this summer.

I was able to meet with the Liana team in Miami. Liana is a wallet that lets you recover coins after time passes if you lose the keys. Project lead Édouard Paris introduced the genius idea to leverage payjoin’s interactivity to automatically refresh that timelock upon receipt of funds. The advanced use cases just keep rolling in.

Wrapping Up

As we look forward to June, it's clear that payjoin is more than a simple protocol—it's an exciting space for experimentation, collaboration and innovation. And it's a testament to the strength of our community, which is never shy about exploring new ideas and pushing boundaries.

Whether it's practical adoption, protocol improvements, or advanced use cases, every advancement brings us one step closer to a more resilient Bitcoin network. I would like to thank all contributors and supporters who make this possible.

So here's to another month of sharing, learning, and growing. If you have thoughts or ideas, don't hesitate to share. Your participation helps drive the payjoin community forward.

And remember, every time you use payjoin, you're not just enhancing your own privacy, you're also helping to strengthen the privacy of the entire Bitcoin ecosystem. So keep joining, and let's make June the biggest month yet for payjoin.

See you next month, joiners!

Best,

Dan

Unlike single-source batching, multi-source optimizes payment flows requiring sequential transactions, like exchange withdrawals to fund lightning channels, into a single transaction. The new ability to batch sequential transactions significantly improves what was thought to be the best case fee savings of payment batching. The release of this week’s interactive batching with payjoin essay could not have been timed any better. I’m happy to be able to share even more payjoin progress updates with you this week too.

BOB Radio invited me to speak on Bitcoin Privacy Tools and Practices with Gandlaf21, Dan Gould & Giacomo Zucco. Giacomo listed the three main levels of privacy to concern yourself with, and we broke down how to address each one, aiming past controversy to deliver actionable advice. BO฿ Space, is a Bangkok based bitcoin incubator and co-working space. Those building and designing on bitcoin are encouraged to apply for residency. Their first cohort will be anounced May 15.

Finally, I’d like to congratulate Will Owens. Payjoin has a new dedicated contributor. Will has been recruited to integrate payjoin into the BDK-CLI by the Summer of Bitcoin internship program. He will deploy a second Bitcoin Dev Kit payjoin integration, following BitMask’s. This work should establish a common pattern and documentation to integrate payjoin with any wallet using the kit. Will’s stated his goal “to help make Bitcoin more accessible, secure, and private for all users” and his plan to use payjoin as an entrypoint to address Bitcoin fungibility, privacy, security, and efficiency in his application. Will, I am eagerly looking forward to collaborating with you and witnessing the exceptional work we will accomplish together. Congratulations.

Sincerely,

Dan

The term "payjoin" is used to describe both an interactive way to build transactions between peers on the web, aka Pay-to-Endpoint (P2EP), and an ambiguous transaction structure, typically with many inputs and two outputs that I dub canonical payjoin. Canonical payjoin looks like transaction behavior that any wallet could make, but its inputs actually come from more than one person. Breaking the assumption that all transaction inputs belong to the same person breaks the foundation of blockchain surveillance and the sole privacy problem left open in Satoshi's whitepaper. In an effort to improve bitcoin's privacy through payjoin adoption, I outline a number of ways payjoin can significantly reduce fee expenditure and increase blockchain throughput for both individual and enterprise circumstances.

Some of these new techniques preserve privacy for transactions otherwise thought of as unambiguous and certainly traceable. The examples mostly ignore mining fees for the sake of simplicity.

Before the Batch

Naive Payments

Payjoin without the joi is just payn. ouch.

A's input0:  2 btc        output0:  4 btc B's address0
                     🔀
A's input1:  3 btc        output1:  1 btc A's change

A typical bitcoin transfer from Alice to Bob looks like this. Note that only the addresses and amounts are posted to chain with no further relation between inputs and outputs. The named labels are not. Third party analysts assume both inputs come from the same entity (because they usually do). They also assume output0 is the payment because neither input is alone sufficient to make a payment of 4 btc.

Canonical Payjoin

Payjoin foils that assumption because it lets Alice and Bob both contribute inputs. What would be interpreted as a naive payment might actually be a payjoin. Assuming both inputs always come from either Bob or Alice is wrong.

A's input0:  2 btc        output 0:  4 btc B's address0
                     🔀
B's input1:  3 btc        output 1:  1 btc A's change

Alice only paid 1 btc to output0's 4 btc while merging it with Bob's 3 btc input too. Bob's 4 btc is not the 1 btc amount Alice paid, which is not visible on chain.

Enter Output Substitution

Payjoin output substitution (pjos) lets a receiver like Bob substitute a proposed output with any outputs of equal amount. BIP 78 pjos is insecure over relayed communications and thus forbidden. BIP 78 receivers must run their own authenticated server to use pjos. Serverless Payjoin secures relayed pjos.

The following examines the use of this technique to prevent address reuse, redirect funds to cold storage, forward payments, and batch transactions for massive fee savings.

Minimum Effective Interaction

Now for not-quite-payjoin but something still fun. Call that Payjoi. Joy is back. Hah 🥁💥.

If Bob's wallet is empty or he's using a cold wallet this would still work.

Imagine Bob's a bartender who posts his “payjoi” QR code on an the wall at the bar:

bitcoin:address0?pj=https://payjoin.bob.cash

Alice would scan it to propose the transaction as usual, but Bob returns the payjoin proposal with one tiny change. By doing so he keeps his tips private from nosy neighbors at the bar.

A's input0:    2 btc        output0:  4 btc B's address1
                       🔀
A's input1:    3 btc        output1:  1 btc A's change

See, Bob swapped output0's address0 for address1. Other patrons do not know of address1 since Bob sent it online as a payjoin proposal. They can’t look up what they don't know.

Payment forwarding

Toys aside, substitution is powerful. What if Bob planned to pay his Cloud provider next time he got paid. He could substitute Cloudy's address instead of his address1.

A's input0:    2 btc        output0:  4 btc C's address
                       🔀
A's input1:    3 btc        output1:  1 btc A's change

Alice only sees Cloudy's address as unique, and the payjoin proposal is authenticated by Bob, so both of them agree that this payjoin pays Bob. Since transactions are atomic, Bob takes no custody of the funds going to Cloudy either.

Bob could also turn this into a canonical payjoin by adding input. Or instead, Bob could forward funds to his cold storage rather than to Cloudy. That could be valuable if Bob's payjoin server hot wallet had more funds than he was comfortable with keeping online. Alice even still pays the miner fee as she would in any case. Bob saves the block space, time, money and hassle of a making separate transaction to forward.

Receiver side Payment Batching

We're going to make this more complex, because it scales bitcoin and it's fun.

Imagine Bob is an exchange sitting on a few low-priority withdrawal orders from Dan of 0.6 btc and and Erin of 0.4 btc. When Alice proposes a deposit, Bob may substitute a single output with many, spreading the inbound amount from Alice across multiple addresses. Instead of just address substitution he substitutes the entire output with new ones.

A's input 0:      2 btc        output 0:  0.99 btc  B's address0
                          🔀
A's input1:       3 btc        output 1:  3    btc  A's change

                               output 2:  0.4  btc  D's address

                               output 3:  0.6  btc  E's address

Batching saves mining fees for Bob since Alice already pays for some transaction fee. Bob can take any remaining mining fee costs from his increased transaction's size out of his own output, address0 shown here receiving 0.99 btc to pay an additional 0.01 btc fee. Not shown, Bob could even split Cloudy's output from the prior example to forward Cloudy an exact invoice amount and keep the change.

Prior art all explores sender-batched transactions. It follows that inputs to batched transactions are assumed to belong to the cluster of the entity making payments (Bob, in this case). Receiver side payment batching kills this heuristic analysis, providing multiple new interpretations for payments of few inputs and many outputs.

Lightning Channels

Yes, even lightning channel payjoin outputs are viable. Lightning channels are posted as 2-of-2 P2SH or P2TR addresses.

A's input 0:  5 btc      output 0:  2 btc  B & his peer's ⚡️ channel
                     🔀
                         output 1:  3 btc  A's change

Bob's lightning output helps preserve privacy even more so because it belongs to two parties, both Bob and his channel peer. When P2TR channels are the norm, a stranger would not even know that output0 is for lightning. New standard lightning protocols allow for payjoin output splicing and dual funded channels to achieve the common input assumption-busting result even without BIP 78 as well.

Mix and Batch 🥣

Combining it all forces multiple ambiguous interpretations of the transaction graph. With basic networking, and no coordinator, Both Alice and Bob can pay multiple parties beyond themselves, combine inputs and consolidate funds without fear for being censored.

Interaction lets multiple ambiguous possibilities converge to preserve bitcoin's inherent fungibility. No inconvenient, fee intensive, pre-scheduled, time consuming mixing step required.

Batch Sender and Receiver Transactions to Put a Cherry on Top 🍰

A's input 0:      2 btc    output 0:           1.5 btc  B's address1
                        🔀
B's input 1:      4 btc    output 1:           2   btc  A's change

B's input 2:      3 btc    output 2:           0.4 btc  B's ⚡️ channel

                           output 3:           2.5 btc  C's address
                           
                           output 4:           1   btc  E's address

                           output 5:           0.6 btc  D's address

                           output 6:           1   btc  F's address

Even though amounts aren't equal, these new payjoin constructions provide significant ambiguity to foil vast swaths of heuristic analysis being done today by breaking their most basic assumptions. Because of payjoin's intra-transaction transfers from Alice to Bob, CoinJoin sudoku analysis does not apply.

Even Alice and Bob preserve some privacy in the other's view. Even though one knows the other's inputs, they cannot be certain that any of their counterpart's outputs will end up in their counterpart's wallet or if output substitution has been used.

Progress before rainbows 🌈 and unicorns 🦄

Bob and Alice still know the subtransactions of their counterpart. As of today, Bob still needs to run a server. They each know which inputs belong to which counterpart. While two-party interaction can help a lot, an adversarial counterparty could still report the other's chosen inputs and outputs to build a cluster with an analysis firm. I know those problems remain to be solved, but look how far ahead a simple HTTP interaction can take us.

Thanks to Hunter Beast, Andrew "Kukks" Camilleri, Ishi, Kexkey, Francis Pouliot, and Yashraj for reading drafts of this.

The BIP78 payjoin protocol has been gaining traction in recent years and is now supported by several wallets beyond merchants. Recent additions include the BitMask browser extension (mainnet launch impending), nolooking for LND, and payjoin-client for Bitcoin Core. BIP78 allows sender and recipient to negotiate a payjoin transaction over the web, by allowing both parties to contribute transaction inputs. This foils the primary heuristic strangers use to surveil Bitcoin users. This protocol is gaining popularity as more users become aware of its benefits and as more wallets support it. Still more payjoins are made with protocols other than the most popular BIP78 even if those making them might not think of them that way.

Payjoin Beyond BIP78

In addition to BIP78, there are other ways to spend Bitcoin with inputs from multiple sources that are still fundamentally payjoin transactions, too. Having included them on the Payjoin Adoption page their relationship to payjoin should be examined.

Dual-funded channels (DFC) are a type of Lightning Network channel where both channel peers contribute funds to the channel, rather than just one. This allows them to transact on the Lightning Network in both directions in contrast to channels with a source of funds on only one side. This can reduce transaction costs and increase transaction speed. Sometimes classical payjoins are called, Pay-to-Endpoint (P2EP), with emphasis on their coordination using an interactive web address instead of a static bitcoin address. Like P2EP, Lightning nodes establish channels via publically addressable identifier.

Cahoots’s Stowaway and Stonewallx2 are two other privacy-enhancing Bitcoin transaction methods that combine inputs and outputs between users to secure transaction details. Stowaway makes a payjoin, while Stonewallx2 makes a 2-party equal ouptut CoinJoin. Cahoots methods use a Tor-based Soroban rendezvous to a PayNym. PayNym serves as an endpoint that can be looked up in a public directory to establish secure connection over Tor relays.

Payjoin sans P2EP

SNICKER is another type of transaction where multiple users contribute input to a transaction. Unlike P2EP, its users scan public data on the blockchain to find eligible counterparties. They transact without ever communicating directly. The SNICKER proposal is focused on equal amount CoinJoins, but could in theory be used to make transactions including transfers like payjoin, too (although between non-input-contributing users). Because it’s non-interactive and common-input heuristic breaking, it serves us here to distinguish between payjoin and P2EP.

P2EP sans Payjoin

LNURL is a protocol for generating Lightning Network payment requests and for providing additional Lightning-related information over the web. It enables Lightning wallets and services to provide users with QR codes or links that can be used to initiate Lightning payments or to access additional Lightning-related features. LNURL can also be used to facilitate other Lightning-related tasks such as opening channels and managing liquidity. Being nonchalantly ubiquitous in the lightning world, it proves the pay-to-endpoint concept is convenient and valuable to users.

Share

My week had a few interruptions, so I made the most of it by collecting all of the payjoin projects evaluations in pockets of free time. Ready to evaluate payjoin for your project? Get in touch.

Have a great week.

Dan

Guarantee some Privacy

The most basic guarantee is to break the most common pattern strangers use to spy on bitcoin users. That’s what payjoin does, and why it fits into bitcoin exchange process to protect consumer privacy. This past week we drafted the the payjoin integration with bitcoin exchange software. The most advanced bitcoin exchange in Canada wants to upgrade first. There’s so much more here that I want to blurt out but I’ll keep it simple for now. If you want payjoin in software you use, have the developers visit payjoin.org and message me.

Interview Inbound

In a recent interview I got into the details of so-called “taint” analysis, how payjoin complements existing privacy tools, and the history and progress of bitcoin privacy enhancement. Stay tuned for the announcment.

Payjoin on iOS, Android, and MacOS

BlueWallet fixed payjoin in their latest release. The list of payjoin capable software continues to grow. Can’t wait to see who supports bitcoin privacy next.

Thank you for yours.

All the best to you,

Dan

Decrypt Covers Payjoin

Alyssa Hertig broke down the goals of payjoin.org and how it works into prose rather than jargon:

PayJoins are different. They're a CoinJoin between just two users—the buyer and the merchant—at the time of sale. As such, PayJoins can be baked into the process of buying anything with Bitcoin.

Check it out here on Decrypt. Share it with a skeptic, their mind might change.

Geyser Campaign

The Payjoin project has raised two million sats on Geyser, enough to run basic payjoin server infrastructure for more than a year! Funders are eligible for a Payjoin Supporter nostr badge for their support.

A How-to Deep Dive

When payjoin.org was put up a few weeks back, there was a demand for a step by step walkthrough of the process. In particular, the feedback asked for an explanation of what the Payjoin SDK does so that payjoin could be implemented it in other languages than Rust too. I’m publishing this early draft for feedback in an effort to answer that demand; build, show, and tell, more in public; and to kickstart foreign language bindings support. It should also help the Summer of Bitcoin students get payjoin into the Bitcoin Dev Kit.

Bonus Podcast: Global Bitcoin Fest Taiwan 🎧

My heart is in Taiwan, and its bitcoin scene is taking off. Virtually all of the ASIC chips for miners are manufactured there. Listen for a history and the future of bitcoin business, manufacturing, policy, and culture in Taiwan. It’s worth a listen.

Wishing the best weekend to you & yours,

Dan

Subscribe now