PDK is here to make Payjoin a drop in upgrade for all software touching Bitcoin. I cover the project's history, why you should consider it to add Payjoin to your stack, and some of the project's priorities moving forward. The PDK team will be updating this new blog with development updates, feature forecasts and the details of releases.
Hi All,
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.
Hey Joiners,
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.
This past week's fee market demand brought up much discussion on scaling. I'm seeing more frequent independent thinkers land on interactive batching like payjoin as a solution. Lots of people understand batching as when an enterprise sends lots of transfers to many parties in one transaction. I call this single-source batching, since only one party has input to the batch. Payjoin enables multi-source batching, where two parties contribute to a batch paying one another and various third parties while consolidating their own wallets to save in fees.
A high fee bitcoin always triggers a search for more efficient use of block space. Blockchain is a slow database, and batching has got to be one of the oldest ways to optimize a database. Lightning is interactive payment batching based on intermittent settlement. Payjoin is interactive settlement batching. Merchant to customer payjoin is what led to the formal BIP 78 spec. It's no surprise then that a merchant / customer frame stuck versus a frame payment batching like lightning. Lightning has been batching for scaling all along. The following outlines how payjoin fits into batched transfer settlement infrastructure and how it helps prepare for the next wave of blockspace scarcity while beating blockchain spies' most common tools as a bonus.
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.
In February 2009 Satoshi posted: "The root problem with conventional currency is all the trust that's required. ... Before strong encryption... privacy could always be overridden by the admin based on his judgment call weighing the principle of privacy against other concerns, or at the behest of his superiors." Since the people we do business with and often even strangers may override bitcoin privacy I have to ask, if communications privacy is protected by strong encryption, what keeps the transfer of value private? The other day, Max Hillebrand noted his "hope" that existing bitcoin tech has already achieved the same level of security in response to Satoshi's words. Crypanalysis defines security against specific attacks a system can be proven to defend from. The tech on offer does not do this to my standard. I know we can extend that tradition and analogy to define the makings of secure value transfer and deliver it with guarantees.
The new payjoin client is live 🖖 Payjoin.org launched the ability to send and receive payjoin from the static website using new Payjoin Software Development Kit. The response proved demand for better ways to collect payments without revealing the destination of those funds to the public. This experiement created loads of feedback we can use to help your favorite wallets and business integrate this bitcoin privacy upgrade.