{ "episodeId": "SLP753", "speakers": { "stephan": { "name": "Stephan Livera", "role": "host", "tag": "STEPHAN" }, "dan_gould": { "name": "Dan Gould", "role": "guest", "tag": "DAN" } }, "segments": [ { "speaker": "stephan", "time": "00:00", "start": 0.0, "text": "Hi everyone, and welcome back to Stefan Laverda podcast. Joining me today, or rejoining me today, is Dan Gould from Payjoin DevKit. He is a maintainer there, and also from the Payjoin Foundation. Dan, welcome back. It's been a while. give us kind of the quick update. What's, what are some of the big updates or high level thoughts on Payjoin and Payjoin DevKit since then?" }, { "speaker": "dan_gould", "time": "00:20", "start": 20.0, "text": "So since we last spoke, Stefan, thanks for having me, by the way. we've come a long way in terms of the actual API for Payjoin DevKit. So one point zero is imminent. I'm talking maybe by the time you're hearing this, it's out, like sometime this week, which means people can take the DevKit off the shelf and make the Payjoin coordinated transactions in the wild, with some vibe coding. I wouldn't push to production, but with some vibe coding" }, { "speaker": "stephan", "time": "00:49", "start": 49.0, "text": "Gotcha. Yeah. And just for listeners who aren't familiar, let's kind of take it back a bit. For people who don't know what a pay join is, what's like the elevator pitch or the very short, you know, a few sentence explanation, what is a pay join?" }, { "speaker": "dan_gould", "time": "01:01", "start": 61.0, "text": "Yeah, so payjoin is the most fundamental way for two people, sender and receiver, to batch a transaction together. So Satoshi, way back in the original white paper, said that transactions necessarily reveal all the inputs belong to the same owner. And Payjoin uses some interaction, meaning the sender and the receiver wallets talk to each other in order to both contribute inputs to the transaction, which has some benefits for cut-through and scaling and breaks this one assumption that Satoshi left in the white paper as a little, Sort of treat of where to go to address the privacy problems." }, { "speaker": "stephan", "time": "01:45", "start": 105.0, "text": "So what's the current state of adoption?" }, { "speaker": "dan_gould", "time": "01:49", "start": 109.0, "text": "So right now Full Bitcoin, Mobile and Cake are the two big pilots with real users in the wild. You can go to the app stores, download their apps, and try a payjoin today. There's a reference implementation that we maintain, Payjoin CLI, that connects to Bitcoin D, and there's another sort of reference implementation using BDK, that's the BDK CLI, but you'll see a lot more developments in the coming months. There's a, BTC Pay plugin that's been a community effort. Valora and Traveca, because it's, particularly are working on, and, yeah, those will, those will come out to support the new async Payjoin stack." }, { "speaker": "stephan", "time": "02:33", "start": 153.0, "text": "Yeah, so just quickly explain that also, the V1 versus V2 of Payjoin." }, { "speaker": "dan_gould", "time": "02:38", "start": 158.0, "text": "Sure. So, like I said, pay join is when your sender and receiver both interact to create this transaction by cooperating, and There's been many different attempts to do this. the first one that took off was in BTCPay Server by, the, the Emperor and Mr. Cooks. And it required that the receiver run a server. So the receiver was already running the BTCPay server, so they had a website with a secure endpoint that the sender could connect to to do those messages. This presented a couple problems. One was the, the fact that you need to run this actual infrastructure, you need to get a TLS certificate, which means you need to like, you know, prove that you own a domain perhaps, and your server needed to be online with a hot wallet. You only had like a thirty second window the way the protocol was It's working. So over the past two or three years, a team of us have developed Tip 77, Async K-join, which has some backwards compatibility with the old one, still limited by the, the old constraints, but if both sender and receiver are using the new async protocol, then they store and conduct their- Interaction, their communication through a untrusted third party mailbox server. So it's just like email, where you put your mail on someone else's computer and you go retrieve it later, and both parties do that, and the protocol specifies that the blobs that go in the mailbox, the mail, if you will, are of the same size and, indistinguishable from randomness." }, { "speaker": "stephan", "time": "04:25", "start": 265.0, "text": "Gotcha. So I presume there's like some batch payments going on here. Is there a default level of batch? Is it like every minute? Every ten minutes or how does that work?" }, { "speaker": "dan_gould", "time": "04:33", "start": 273.0, "text": "So the-- this is where Payjoin differs a lot from the old approaches to Bitcoin privacy, our older alternative, like the ones that have been around longer. the reason Payjoin is new is because the batch just happens when the participants to a transaction wanna take some economic action. So, Stefan, I wanna send you some Bitcoin, and so rather than just post a Bitcoin transaction to the network Because you're accepting Payjoin, I can send you a proposal, which you could yourself broadcast to the network, or you could return to me a batch where, say, you wanna do a consolidation, or you wanna, you know, you wanna send my coins to an exchange right away or to pay someone right away. We combine our intents at the time of a transaction, so when you typically do settlement, to do the batch and The reason I drew the comparison before is because, like, in your, coinjoin, equal amount coinjoin with many, many people, everyone's kind of waiting around until there's enough people to create a batch where they're sending to themselves. Payjoin is bringing multiple clusters together and offering an opportunity for different economic actors to actually do both a transaction or multiple transactions that they both wanna do, with the opportunity to Batch, not specifically to do some equal amount." }, { "speaker": "stephan", "time": "06:02", "start": 362.0, "text": "Gotcha. So it doesn't have to be kind of waiting in a pool for a batch to occur. it can, let's say, it can appear more or less instantaneous, is the question I guess I was getting at." }, { "speaker": "dan_gould", "time": "06:14", "start": 374.0, "text": "Yeah, instantaneous if both people are online. the cool thing is it works with mobile phones, so if you put your phone in your pocket, say you receive money, you wanna receive some money, you send me your address. The payjoin URI encodes all the information to let us communicate out of band. You send me the address, you put the phone in your pocket. I start the transaction, you're not online, so it won't finish, but my phone will say pending pay joint, and I'll text you, and I'll say, \"Hey, it's fun. Like, you're waiting for this money, check it.\" You open your phone, it then connects back to the server and, sends me the back, the process, sends me, sends me that back, and then when I open my phone, the transaction completes. So it's, it is interactive. Okay, so" }, { "speaker": "stephan", "time": "06:52", "start": 412.0, "text": "there is some round of back and forth there, but- Yeah. Okay Yeah, it's with" }, { "speaker": "dan_gould", "time": "07:02", "start": 422.0, "text": "Payjoin DevKit. So because, because of the way the protocol works, if for some reason you never came online, you're never worse off than before. You can always open your phone and broadcast what we call the fallback. So the transaction you would, you would have sent otherwise, as in" }, { "speaker": "stephan", "time": "07:20", "start": 440.0, "text": "the non-colaborative version of it, yeah, gotcha. Yeah, yeah. And then practicality for developers. Now, you-- I think on your website you said a wallet can integrate Payjoin DevKit in under two thousand lines of code. So tell us a bit How realistic is that for different teams?" }, { "speaker": "dan_gould", "time": "07:33", "start": 453.0, "text": "So I'm not sure what exact article you're quoting there. this is a few months ago probably where we did an example using Bitcoin D, probably based off of a Payjoin CLI, bare bones." }, { "speaker": "stephan", "time": "07:45", "start": 465.0, "text": "okay." }, { "speaker": "dan_gould", "time": "07:46", "start": 466.0, "text": "Yeah, so that's like If you, if you just wanna do the actual process plugged into a wallet, it is, I would say, a-around there. It's certainly less than ten thousand lines of code. You would follow the reference example, and you have to do a couple things. You have to serialize the state to the database, because, like I said, it's async, so when you put your phone away, you gotta pick it up and resume the state. You have to serialize some network messages, so the messages we're sending back and forth, and you have to follow the rules of the transaction construction, so you communicate Your intents are, what kind of fees, your coin selection, and then the Payjoin dev kit abstracts all the other protocol information away. So if you do those things, some configuration, you're off to the races." }, { "speaker": "stephan", "time": "08:29", "start": 509.0, "text": "I see. And then the, is it oblivious HTTP and like the, the server that you're using to, to do the async part, how does that work? Is the wallet developer building that, or are you using like already existing servers for that? Can you explain that?" }, { "speaker": "dan_gould", "time": "08:46", "start": 526.0, "text": "There are a few Infrastructure runners in the community right now. So if you open full Bitcoin and CAC, they're baked in and you can-- there's some like defaults and you can configure them, but anyone can run the server if you go to github.com/pagejoin, you'll see the Rust Pagejoin repo. We've got the mailroom, we call it, which is the combined ohttp relay and directory. Now what the hell is that? Basically every time, Pagejoin happens and you put things in the mailbox, the- The mailroom, the directory server, within the mailroom, and the protocol insists that you reach it from oblivious HTTP, which means you proxy one step, so you're not gonna reveal your IP address directly to the directory so that They don't have that information to correlate, okay, these two IP addresses are doing, an economic transaction together. The IP address is revealed to the relay only, and then the directory gets the encrypted blob. so that that leak just doesn't happen by default. This was one of the gaps in the original protocol is you're using an HTTPS server, so your sender is always connecting directly to the receiver and you learn their IP address. That's no more with Oblivious HTTPS." }, { "speaker": "stephan", "time": "10:05", "start": 605.0, "text": "I see. another criticism I've seen from, I believe Shinobi was saying that basically people can still do clust-- wallet fingerprinting heuristics and, use that to take away any privacy gain. So Do you have any thoughts or any response to that?" }, { "speaker": "dan_gould", "time": "10:24", "start": 624.0, "text": "Yeah, of course. I think unfortunately, Shinobi is more right than he is wrong when it comes to basic payjoin, and there's always a long horizon here with what needs to be done, with payjoin. The Bib seventy-seven payjoin v two isn't the, the all end-all. Basically The protocol as it exists does one thing for privacy, which is break the common input ownership heuristic. So you can basically that one assumption that Satoshi left us, that all the coins belong necessarily to one person, is no longer the case. But there is still timing of, specific clusters. Maybe one cluster of coins is only active during East Coast US time, and another cluster of coins is only active during- During, you know, Sydney time. there are-" }, { "speaker": "stephan", "time": "11:22", "start": 682.0, "text": "And then at the wallet fingerprinting level? Yeah." }, { "speaker": "dan_gould", "time": "11:24", "start": 684.0, "text": "Yes, yeah. So a sophisticated- Analysts, while they might not be able to rely strictly on the common input heuristic, there are other heuristics that are Now being understood, Armin Sibori wrote a great post on payjoin dot org about this, and more being discovered, and the only path forward is really to do multi-party batching. So right now, what exists as Payjoin is the most fundamental way to do an interactive batch, with the idea that the Payjoin DevKit is a platform that Wallets can use to supercharge their batching. you know, regular batching, single side batching has been around for a long time, and then as the State of the art develops, we should be able to combine more transaction intents together and make it So it's less effective to rely on these clustering heuristics to surveil people." }, { "speaker": "stephan", "time": "12:31", "start": 751.0, "text": "I see. So I guess for now, maybe it's more like if you use a particular kind of wallet, let's say Ball Wallet or Cake Wallet or others, you kind of end up Being inside the anonymity set of that specific kind of wallet, like let's say bull wallet or cake wallet, you're with all the other cake wallet, like you'll have the same fingerprint as them, right? To some extent. That's one thing, that's one way to think of it." }, { "speaker": "dan_gould", "time": "12:52", "start": 772.0, "text": "Unfortunately, there's, there's problems beyond that. Like I said, if, if one person's in Boston and another person's in Sydney- Right, that's" }, { "speaker": "stephan", "time": "12:57", "start": 777.0, "text": "on the timing side. They may" }, { "speaker": "dan_gould", "time": "12:59", "start": 779.0, "text": "have some fingerprints beyond even which wallet, or like if you're using Liana, you might be able to get Directly, like," }, { "speaker": "stephan", "time": "13:13", "start": 793.0, "text": "yeah, gotcha. So there'll be all these other little fingerprints and heuristics that can be used by, let's say, the chain surveillance, firms, but at least, I guess you're trying to say it's at least one step harder because you're undermining the common import ownership heuristic, which is the main heuristic." }, { "speaker": "dan_gould", "time": "13:28", "start": 808.0, "text": "That's the most fundamental one Satoshi left in the paper. There is some work being done that can be done by the wallets too. There are some kind of brain dead fingerprints that just get left accidentally 'cause people didn't think, and I think this work that's been done recently, as well as a bunch of the PRs made by, Cindy, a contributor, are Addressing these fingerprints wallet to wallet, and they're bringing up a discussion even on Bitcoin Core about the types of fingerprints and the trade-offs deliberately rather than happen- Now," }, { "speaker": "stephan", "time": "14:02", "start": 842.0, "text": "to be fair, we have been talking mainly, a lot of the recent discussion just now was about the privacy side of it, but there is still the, the efficiency side of it. As I understand, there's a batching benefit to this, and that maybe over time, exchanges or custodians and users by participating in these pay join batches can actually save fees. So you're not- Elaborate a bit on that." }, { "speaker": "dan_gould", "time": "14:24", "start": 864.0, "text": "Yeah. So all the expense to the transaction comes from the input, basically. The input is like ten times more expensive than the overhead of the transaction. So when two people batch, yes, they save the overhead of the transaction, but where the real savings come from is net settlement. So if I'm making a deposit to Bull Bitcoin Exchange once they turn Payjoin on, and someone else is making a withdrawal, that deposit of mine can directly fund the withdrawal so that Bull never even needs to take that coin into their treasury and into their custody, and they don't need to be encumbered by the fee that they'll incur in the future for them to spend. This is something that hasn't really rolled out yet. We just saw the, Cashu Dev Kit and the Bark team do a cut-through to join a Cashu. Backed by an arc where they cut through one of these transactions, so they do one transaction instead of two, and that sort of net settlement is where I think the great savings come, but it's, it's a new space. We're seeing the first grassroots adoption, I'm talking literally, you know, within the past two months." }, { "speaker": "stephan", "time": "15:36", "start": 936.0, "text": "And so, talk to us a little bit about the future roadmap there, this idea of multi-party pay join." }, { "speaker": "dan_gould", "time": "15:42", "start": 942.0, "text": "So for the foreseeable future, since we've just got the- 77 Payjoin, like in pilots, we're focused on getting those integrations out into the world, but on the website there is a roadmap that's in phases. of decreasing trust assumptions to batch multiple people together. this is going to be likely a year's long roadmap, and the plan is for it to be demand driven. What's really important is that we follow The appetite that the wallets and services have, 'cause we've seen this sort of pay-to-win idea been around for almost a decade now. I think 2017 is when, BIP 78 came out, and it was sort of- People had these complaints and it wasn't addressed, and so my perspective is that you can meet the developers, the wallets, the services, where they're at, where the demand is, and get feedback to figure out the next thing to build. So we're focused on Polishing the BIP seventy-seven draft, it's not even a final BIP yet, before we move on, but it is inevitable and necessary to evolve the protocol into a multi-party one in order to fully realize the sort of privacy transaction" }, { "speaker": "stephan", "time": "17:10", "start": 1030.0, "text": "cut-through privacy, benefits. Okay, great. Yeah. So I guess, so I guess summarizing, there was V one in the early days, but you kind of-- most people had to have like a BTC pay server. I remember I had one as an example. Now V two is the version where- We're on now, which, you know, takes away, some of the requirements and makes it asynchronous, and then maybe someday in the future we'll have V3 where it's like multi-party batching, as an example. But for now, you're focused on, you know, obviously getting people to use V2 of Payjoin using Payjoin DevKit. So, I guess final, call to action or, closing thought, what should, you know, for people who wanna learn a bit more about this, how do they get involved or use it" }, { "speaker": "dan_gould", "time": "17:51", "start": 1071.0, "text": "So wallet team developer exchange, you should reach out directly. Twitter at Big Gold or at PageOneDevKit are great ways to contact us. PageOne dot org has some of these explainers, and then if you go to GitHub dot com slash PageOne, you should be able to pick up the docs and code we have and get something working, like I said, in a weekend at this point, one point oh, it'll be out, you know, give it a day or two." }, { "speaker": "stephan", "time": "18:17", "start": 1097.0, "text": "Excellent. Well, thanks for joining, Dan. See you around." }, { "speaker": "dan_gould", "time": "18:20", "start": 1100.0, "text": "Thanks, Devon." } ] }