Tracking Growth in Payjoin Adoption

Dual-funding, Cahoots, ... SNICKER, and LNURL?

Payjoin adoption has been increasing steadily since its introduction in 2018. Payjoin started as a privacy-enhancing technique to allow merchants to combine their Bitcoin with customers, to save fees, and to better secure the origin and destination of their funds. It makes it more difficult for third parties to track and analyze Bitcoin transactions in general, which is a significant benefit for anyone who values financial privacy. This past week I documented the growth of the technology in a few big tables on the Bitcoin wiki.

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.

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