{ "episodeId": "SLP576", "speakers": { "stephan": { "name": "Stephan Livera", "role": "host", "tag": "STEPHAN" }, "stephan_livera": { "name": "Stephan Livera", "role": "guest", "tag": "STEPHAN" } }, "segments": [ { "speaker": "stephan", "time": "00:13", "start": 12.63, "text": "Hi everyone, welcome back to Stephan Livera podcast brought to you by Swann dot com, the best place to buy Bitcoin. Joining me today is the lead of Payjoin Dev Kit and also, I believe this project, and you are sponsored by Spiral and Opensea. So, Dan, welcome to the show. Thanks for having me, Stephan. Fun, can't wait to get into it. So I know, there has been a bit of discussion recently about the state of Bitcoin privacy. Obviously, some of the recent news with, the arrest of the founders of Samurai Wallet and of Wasabi exiting the US, it's-- there's been a lot of discussion of, okay, where do people go now for privacy? And what are the-- what does it mean for Bitcoin privacy? So, do you wanna just start with that, start on, if you have any broader comment about what's happening there?" }, { "speaker": "stephan_livera", "time": "00:57", "start": 56.68, "text": "Yeah, it's- Of course, been very difficult to see one after another developer have a target on their back, especially if what they're working on is open source software that gives people the freedom to selectively reveal their activity to whatever counterparty they want. I think the approach that a lot of this tech has been taking is one that we knew wouldn't last forever. A lot of people had concerns. Of course, I hope that the powers that be see that this tech is speech acts The, the deployment of the tech is just a, an act of speaking, but I think we need to change Bitcoin in the cultural systemic way we use it. If we're going to have reliable privacy for the long term, where a lot of these attacked pieces of software are specific applications that someone who has a particular interest in privacy might use It would be better if, as a ecosystem of independent applications and software, there were some reason for us to use privacy tech to save money or to scale Bitcoin that had ripple effects over the whole ecosystem, and I think that's where we're definitely headed." }, { "speaker": "stephan", "time": "02:28", "start": 148.01, "text": "I say, yeah. And of course, I mean, you know, free the samurai guys and free the Tornado Cash guys, as far as I'm concerned, but, it certainly could contribute to a chilling effect, in the US or even outside of the US, given what's happening. But of course, there's, you know, there's fighting back, right? There's some fighting back that's happening at a political and legal level, but there's also developers who are writing open source code, and that open source code could, as you were saying, go into some of these Bitcoin wallets and Bitcoin apps in such a way that it, it's not like the only user of this app is someone using-- looking for privacy. There may be You know, efficiency or scaling reasons, or just maybe just it's a better UX, like it's just a better experience to use that app. So let's talk a bit about that. Obviously we're, we're gonna talk a bit about the Payjoin Dev Kit, but, do you wanna just start with the background for us? What is a Payjoin?" }, { "speaker": "stephan_livera", "time": "03:24", "start": 203.78, "text": "So a Payjoin is the simplest way for Two people to cooperate to make one transaction. So I wanna send you some Bitcoin, you wanna consolidate some of your unspent outputs, because as you use Bitcoin over time, if you're receiving money, you have to eventually spend that, and every single output needs to be included in a transaction to be spent. And if you spend it at a time when it's expensive to include things in the blockchain, you're gonna incur more fees than if you peer- Periodically consolidate. So" }, { "speaker": "stephan", "time": "03:59", "start": 239.14, "text": "yeah, because-- Sorry, let's just, just before we go further, I just wanna make sure we've explained it every-- Obviously, I understand, you, you get this, and probably many listeners do, but just to make sure everyone can follow along, Bitcoin transactions are made up of inputs and outputs. Those inputs are consumed in the transaction, and it's like, as an example, I might, let's say, I pay you just in a standard transaction, that transaction might have one input on my side, you know, one input from my wallet, and it might have" }, { "speaker": "stephan", "time": "04:27", "start": 266.92, "text": "to you, and then the second output in that case might be a change output coming back to me. So the analogy for listeners who aren't familiar, you can think of it like, you know, it's notes in your wallet, right? Like if I'm gonna pay you, you know, twenty-six dollars as an example, I might need to pull out a twenty-dollar note, a five-dollar note, and a one-dollar note to be able to pay you in, in this kind of analogy. And so what you're talking about there is our Bitcoin wallets in a Payjoin context are maybe gonna coordinate Who's putting, who's contributing the inputs to that transaction? so do you wanna just, you know, take it from there and ex-elaborate a little bit on that?" }, { "speaker": "stephan_livera", "time": "05:07", "start": 307.13, "text": "Yeah, so Like you said, Bitcoin transactions have these inputs and outputs, and in the original white paper, Satoshi actually saw that this was a problem for privacy. This is the only problem related to privacy that's left in the white paper, that if I'm going to make a transaction, I'm going to contribute all of the inputs, so anyone looking at that transaction on the public ledger is going to know that those inputs came from the same person. So that's called common input ownership assumption, and the way to fix that is by constructing transactions where more than one person contribute inputs, and Payjoin is the very simplest way to do that automatically." }, { "speaker": "stephan", "time": "05:51", "start": 351.3, "text": "Yeah, right. And as you said, the common input ownership heuristic, is one of the key privacy destroying, assumptions. I think it's probably one of the key things that people are using in terms of if you are An outside observer, right? Because for listeners, obviously I know you get this. For listeners, Bitcoin is a public ledger of transactions, and so anybody who downloads the blockchain can just look at that, or people can even use these block explorer websites, and then they can sort of trace where things are going on the chain per se, and so one of the key-- now, there's a bunch of different heuristics to be clear, right? There's things like the output type heuristic, there's the, kind of the, the numbering of the outputs, there's, you know, there's, end sequence numbers, there's all kinds of things, but in terms of the main one that a lot of people use and to- Put some context here. This kind of analysis is also, people call it wallet clustering. So the idea is the outside observer, chain analyst person, might try to look at those flows on the chain and sort of identify, \"Oh, okay, I can sort of see there's a cluster of these coins that have maybe come from this particular direction.\" And so by using this Payjoin type of technique, it actually helps break that heuristic because now you can't necessarily know just because these outputs were spent at the same time, they're not necessarily Controlled by the same person." }, { "speaker": "stephan_livera", "time": "07:22", "start": 442.17, "text": "That's right. And very importantly, the types of batches that we do don't look any different from Typical activity that's done on chain. So there's a lot of these transactions that use multiple outputs at the same time to fund an output that's maybe bigger than some of the inputs. So if I wanna pay you twenty-six dollars, I need to get my twenty-dollar note, my five-dollar note, and my one-dollar note. You have those inputs to create this, This output. So this type of behavior, type of structure that Payjoin makes on chain is covert and it creates this discrepancy between, is this, naively constructed transaction in the old school way or is this a Payjoin? So you get this- Benefit of batching where because our payment intents are together, we can save some money on the combined intent versus if they were posted independently, because every byte you post to the ledger you need to pay for. And we have this privacy benefit not only to ourselves, but to everyone on the network, because any transaction that could potentially be a payjoin now has some uncertainty about it. It's more difficult to run a, a dragnet surveillance system across a network that has that level of uncertainty." }, { "speaker": "stephan", "time": "08:48", "start": 527.97, "text": "I see. Yeah. And so in other words, it's like the anonymity set is much larger. And from what I've heard from, privacy analysts and developers, people like, Adam Gibson, aka Waxwing, he's spoken about how you would only need a relatively small number, small amount of Bitcoin transactions to be payjoins before it's casting doubt On all Bitcoin transactions in terms of their traceability or casting doubt on the common input ownership heuristic. So I'm curious if you have any thought or reflection on that." }, { "speaker": "stephan_livera", "time": "09:22", "start": 561.52, "text": "Yeah, everyone wants a number. Everyone's like, \"What's the number that makes-- After what, after what point does Bitcoin have privacy?\" And Of course the answer is complicated, how could it be simple? So the important thing is that when there's a s-- st-- statistically significant number of payjoin transactions, when you look at any transaction on chain and there's a significant probability that you could be looking at a payjoin or not, then we're winning, then this privacy has a strong effect, and it's affected by not only the other people that are using Payjoin, but what wallet you're using, like you said, what other fingerprints you have. connections to other people who might be revealing the true nature of a transaction and removing those privacy properties. So Payjoin isn't a fix-all for privacy, but it creates-- it, it raises the lower bound on everyone's Expected privacy. And this is, this is maybe flip to say, but I think around five percent is considered statistically significant For a lot of circumstances, it's just a rule of thumb. So if there were a five percent chance that your particular transaction was a payjoin, then that is Something that someone tracking that transaction would need to take into consideration and, and think about." }, { "speaker": "stephan", "time": "10:50", "start": 649.95, "text": "Yeah. And as we were saying, now it's important, we'll get to the kind of, it's not a silver bullet point as well, but I think the important point to make here is that it really screws with the ability to do clustering, right? So the idea is if the outside observer or the surveillance person is looking on the chain, they have a lot less capability to understand the flows. Because now there's a significant number of people who are actually using Payjoin in, in this hypothetical, right? But also to the point you mentioned, it's-- and I think this is something I was commenting on this earlier that I think we have to get away from this idea of silver bullet thinking, right? This kind of, \"Ah, just this perfect bullet, I loaded and it's, I just do this one thing and I'm done.\" Well, not quite. It's more like there are other ways that you could be de-anonymized, right? It could be through your internet" }, { "speaker": "stephan", "time": "11:43", "start": 702.69, "text": "Broadcast that transaction. What was the, you know, there's all these other, things, maybe like timing attack, or timing analysis of the, the volume of coins. Like, there's all kinds of other ways that, some of these, surveillance techniques could be applied. But I think the important point to understand is this isn't, this could be a really cool tool that step-ma- that moves it forward in a, in a meaningful way. So that's how I'm thinking about it. I'm curious, if you're seeing it similarly" }, { "speaker": "stephan_livera", "time": "12:13", "start": 732.82, "text": "Yeah, even within the tools that exist, you're going to have incremental changes of efficiency or speed. To me, the most important thing about Payjoin is that it doesn't require a fork to Bitcoin, and wallets can implement it just by changing the way they communicate over the internet. It's Application level software, it can be applied to most of the ways people transact in Bitcoin today, and it's compatible with a lot of the other ways people want to use Bitcoin like Lightning. It just makes the settlement layer more efficient and has privacy as a sort of side effect." }, { "speaker": "stephan", "time": "12:54", "start": 773.83, "text": "Yeah. And we should also mention, as you were saying before, the benefit isn't just privacy, but potentially being able to, let's say, manage your wallet a bit more. So let's say your wallet has, you know, in this analogy, you've got a bunch of different coins. The idea is that wallet can use different inputs to then manage the size of the wallet and the inputs that it has, right?" }, { "speaker": "stephan_livera", "time": "13:18", "start": 797.99, "text": "Yeah, it gives you An opportunity. So you're going to need to do this consolidation no matter what if you're receiving Bitcoin flows and not, not receiving. And typically during a payjoin, a sender is offering you Enough fee to cover your consolidation, so you have this free option every time you get offered a payjoin to make this consolidation and save money in the future, and you also have the opportunity to do really fancy things like transaction cut-through, where if I want to send you some money, you don't have to take that into your static address because we are actually interacting over the internet, you can say, \"Actually, I want some of the funds you're sending me.\" To go to my broker who's gonna cash me out to fiat, I want some of it to go to my cold storage wallet and I want some of it to go into this lightning channel, and then you send that request back to me, I can just check that I'm still paying you, and you're not spending more than I'd like to, and you get that efficiency gain." }, { "speaker": "stephan", "time": "14:25", "start": 864.89, "text": "Yeah, that's really fascinating because then, yeah, you could start to kind of hop, jump through hops as well, so that kind of makes it even more confusing, from a- From a, satellite perspective. And so, I guess summarizing there in terms of this point, it's that it's not just a privacy win, it's also potentially an efficiency gain, and so that's also a really interesting point. Now, you know, there's no free lunch. There are trade-offs, and I, as I understand, there's more interactivity. So if you could just talk us through some of the downsides and some of the potential- pitfalls here around having payjoin." }, { "speaker": "stephan_livera", "time": "15:02", "start": 902.15, "text": "When you're talking about implementing a payjoin in a particular piece of software, I think the efficiency gains are the Key point to communicate to your user base, like we're doing this because you can save money, not necessarily because you get particular privacy from your counterparty, because it helps the whole network. It's not just about the one person doing Payjoin, which is a difference in The way most people have thought about privacy tech on Bitcoin, where they say, \"I, I have Bitcoin, I wanna coinjoin, I wanna get privacy,\" and this is kind of an, an upgrade that lets us Take this trade off of doing a little more interaction to have efficiency gains and only post a limited, a limited transaction that doesn't necessarily reveal all of the characteristics of every single party that was involved in that. But of course, interaction has massive costs I need to make sure I can send you a message and you can send it back to me. So this is a huge reason that the first versions of Payjoin were not able to take off. People who had wallet software implemented the sender a lot of the time, but didn't implement the receiver because the receiver needed to have a server that was reachable on the open internet. Because when we make a payjoin I make a typical transaction and sign it, a basic transaction, we call this the original since it comes from me, I'm the origin. In this story, I send that to you, you look at it and says, \"Okay, this pays me, but I wanna make it a payjoin.\" I'm going to add my input and augment my output by the amount of the input minus fees. You sign that, invalidating my signature, 'cause my original signature was only valid for the complete original transaction you sent it back to me, and then I can check that it follows the rules, and if I like it, I sign it and broadcast it. So there's one round of communication that needs to happen. And that takes time, but we already are doing this to send Lightning payments, for example, all over the place, and what we've figured out is that the real bottleneck isn't Being online most of the time, all of our devices are online, I'm talking to you online right now, it wasn't difficult for us to, to make this happen. What's difficult is being online at the same time, synchronously. So We can tweak exactly how those messages are passed and use some network privacy techniques and some encryption so that no third party can, steal or- Dissolve the privacy properties, but we can have some third party untrusted server be able to move these messages on our behalf with a, a new version two Payjoin protocol that gets over some of the interactivity challenges." }, { "speaker": "stephan", "time": "18:03", "start": 1083.29, "text": "Okay, great. yeah, and as you said, I think that's maybe historically why there's not been a lot of wallets that have taken on Payjoin support, but, from, yeah, so just walking that through a little bit. So as an example, let's say, you have an online store, maybe you have BTC Pay, and actually I know BTC Pay does have, Payjoin support. I, I remember ticking it on, you know, a couple years ago, but anyway, the idea is, let's say I'm Instead, like as I scan that, you know, if, let's say I'm using my phone, I pull out and I scan that, it's got like a little extra bit at the end, d- you know, denoting that, oh, this is a Payjoin, you know, enabled. BTC Pay or Payjoin enabled, wallet, and then at that point we can sort of, you know, my wallet is gonna talk to your BTC Pay or your server and do that process where we kind of hand back and forth the PSBT or I- or I- I think you, you, come back to me with the new PSBT and I sign that and then broadcast, right? That's right. Yeah. And so then let's talk a little bit about, you know, if you have any thoughts on why there hasn't been a lot of Payjoin adoption to now. Has it-- I think one criticism would be, I've heard people say, \"Oh, look, it's, you know, it's like a science project and whatever. People are kind of talking about in theory, but people aren't gonna use it in practice.\" Do" }, { "speaker": "stephan_livera", "time": "19:32", "start": 1172.32, "text": "working on as a science project, you know, you're probably onto something because they felt they needed to comment and you're experimenting, doing something new. So I think there were at one time incumbents who had competing borderline proprietary software or not completely open spec, there wasn't a, an open process to Move the protocol forward, who were threatened by having an open protocol because it would outcompete their app. And like I said, the original Payjoin spec had some problems, wasn't quite there, and there also wasn't a profit motive For a developer to go and improve this privacy technique where they can't charge a fee for every single- A payjoin that gets coordinated because it's a peer-to-peer thing, that's a network upgrade, it's not a specific application upgrade. There wasn't so much Demand, or I guess there wasn't the motivation to, to supply that because there's no, there's no reward. And that's changed the past two years, I'd say. I've been focused on this problem and fortunate enough to get the support of some of these grant-giving, open-source supporting organizations. and I wanna give a shout out to Bobspace in Bangkok and the Human Rights Foundation for supporting this, in addition to Spiral and OpenSats, because they're trying to get this over the line. So there's more and more developers Who are trying to make this happen. There are more people who have standards experience working on this, and the other thing was the bit process was just totally backed up. So the ability for a ecosystem to come to consensus on changes or even discussions around a spec was totally backed up until very recently, and that's, that's changed. So All of those contributed to the Payjoin spec not being ratcheted forward, but in the past year, we've had an upgrade to the underlying specification that's asynchronous and removes the barriers, and we have more collaborators than ever. Trying to move this forward. And then we also have the Payjoin DevKit that lets people take this off the shelf library and plug it into their software so they don't have to worry about implementing all of the Payjoin spec. Correctly or efficiently, we can all collaborate on this, this library that everyone can share, kind of like how, Lightning DevKit has been able to do that for Lightning across the ecosystem." }, { "speaker": "stephan", "time": "22:18", "start": 1337.91, "text": "Great. And so can you, while we're on the topic of Payjoin Dev Kit, can you explain what is Payjoin Dev Kit, how does it work, and, you know, what people can do there?" }, { "speaker": "stephan_livera", "time": "22:27", "start": 1346.62, "text": "So" }, { "speaker": "stephan", "time": "22:27", "start": 1346.78, "text": "software" }, { "speaker": "stephan_livera", "time": "22:27", "start": 1347.14, "text": "development kits have gone back a long time. You take, some common functionality and you put it into a library that has documentation and examples So people can take that library and plug it into their existing software and get some new functionality without implementing it all themselves. Payjoin DevKit does that for Payjoin, for the version one and two Payjoin spec. It's written in Rust, so we can have a high degree of type safety, and there's a reference implementation that consumes the library, the Payjoin CLI that works with Bitcoin D. It also has the server software to do the version two, so these, these mailboxes anyone can run. And because it's in Rust, we're able to bind to it from many other languages, so BitcoinXavier is working on Python and Flutter bindings, so anyone can use this common library that we've all been iterating on and tuning to be better and put it into a different programming environment. So the idea is anyone can take this small, correct piece of library code and use it in whatever wallet they want." }, { "speaker": "stephan", "time": "23:42", "start": 1422.31, "text": "Yeah, and that's great to hear. I obviously would love to see, Payjoin come to more, more and more wallets. so you touched on a few things there. you touched on the server mailbox idea. I believe this might be part of the new V2 spec. So, maybe you wanna just help explain this server mailbox asynchronous Payjoin. And to really call it a Payjoin Directory. I, I didn't mis- mis-speak, I g-guess by calling it a notebook, but it's the dir- so can you explain what the directory is for, you know, payjoin?" }, { "speaker": "stephan_livera", "time": "24:09", "start": 1449.47, "text": "Yeah, so version one payjoin, we communicate peer-to-peer. You have a web server, I have a web client, and I send you messages to your server. But what if you don't run a server? What if you're not a sysadmin? Bleh, it's just a pain. What if you're on mobile? Then hosting a server is be-almost impossible. So instead, we can outsource this directory, this functionality to a directory. So the directory is just a box that allows you to register a subdirectory where I can reach you. So if I want to send you a payjoin, if you want me to send you a payjoin, you first talk to the subdirectory, which is known to your wallet or configured, and you say, \"Hey, I want a subdirectory,\" it says, \"Okay, this is your public key for the subdirectory.\" You can then send me the URL of that directory server slash subdirectory, and I now have enough information to do a key exchange with you. Encrypt messages that only you can see, but put them in this subdirectory folder so we can speak back and forth. That's, that's the basic idea, and by both having that subdirectory and then making the protocol So we don't need to respond right away, we can have this asynchronous communication that's, effective even on mobile. So receivers don't need to host a server anymore." }, { "speaker": "stephan", "time": "25:36", "start": 1535.75, "text": "Back to the show in a moment. This show brought to you by CoinKite dot com, the creators of the best Bitcoin hardware security devices, such as the Coldcard Mark IV and the new Coldcard Q. Now, we use Bitcoin hardware security devices to keep our keys offline, our private keys offline. Now, the way these work is You can do that setup, write down your twelve or twenty-four words on the, the seed word cards, and keep that secure. Now you can use this device to interact with the Bitcoin network using software such as Sparrow Wallet, Electrum, or Bepko Desktop or Nunchuk as a few examples. Now you have a range of security features that you can use with these devices, such as passphrase, you can use seed x or, or my favorite is multi-signature. Now if you're starting in a basic way Just start with the device and the USB-C cable, plug it directly to the computer and use it that way, and then later improve your setup. But I believe these devices are great at helping secure your coins, especially as you start to migrate up into multi-signature security. But don't be disheartened or don't be, scared away, they are accessible, and I think you actually do learn about Bitcoin in the process. So to get yours, go to coinkite dot com, use code Livera to get a discount on your cold card. This show also brought to you by mempool dot space, the leading Bitcoin and blockchain visualizer. I use it all the time when I'm checking transaction fees and trying to understand what is the state of Bitcoin's mempool. You can search transactions, historical as well as unconfirmed ones, and also see a great way to visualize things across the Lightning Network, Liquid, mining, and so much more. Also, for those of you with an enterprise, they offer a mempool dot space enterprise program. So for those of you as- Part of that enterprise program, you might wanna get increased API limits, and you might wanna have increased access to the team in terms of feature requests. You might wanna have special branding in terms of how your custom instance of mempool dot space looks. So to sign up for that, go to mempool dot space slash enterprise. The lead sponsor of this show is Swan dot com, and Swan has a mission to onboard millions of people into Bitcoin. I also work at Swan, helping on some educational con- Content for the team. Now, the team have also put out a new version of the Swan Bitcoin application, which is available on your smartphone, whether it's Apple or Android. Now, this app has a really fast onboarding experience. It's now just a few minutes to go from zero to Bitcoin. So if you are standing there with your family or friends and you might have been having trouble trying to get them onboarded, well, try this now. Recommend Swan Bitcoin, and you can do this while you're standing next to them, they can click through, and most of them will be able to set up And do this in just a few minutes. Also, the team at Swan have rolled out a new promotion, there are zero fees on your first ten thousand dollars of Bitcoin buys. So this is a great way to go from zero to Bitcoin and in a guided and managed way. So reminder, go to your app store or Play Store and search Swan Bitcoin to get onboarded with Bitcoin today. And now back to the show. Okay, great. So a few questions there, just on the asynchronous aspect, you mentioned we don't both have to be online, right? So one of us- Doesn't have to run a web server, we could both be mobile users. What kind of time thresholds are we working with here, just like as a default? Are we talking like within a day and then it times out, or is it just kind of like actually it's always gonna be valid? You know what I mean?" }, { "speaker": "stephan_livera", "time": "29:08", "start": 1747.74, "text": "I think within a day makes the most sense, and this is a configuration option that both the directory and the receiver would be able to coordinate with. There hasn't been enough Feedback yet to know for sure i what the, the number is, but I think twenty-four hours is a typical Lightning invoice expiration, I think that makes sense in this context too." }, { "speaker": "stephan", "time": "29:30", "start": 1770.45, "text": "Gotcha, yeah. And just to explain a little bit of context for maybe listeners who are newer, in the kind of older days of Bitcoin, now, this isn't a recommended practice, but there were people who would use a stand-- a static address as an example, or maybe, or even if they weren't using a static address, they might sort of tell someone, \"Oh, let me generate a new address in my" }, { "speaker": "stephan", "time": "29:50", "start": 1790.3, "text": "And they just pay it whenever, right? Because that's kind of how things work on chain. It's just kind of a long-lived Bitcoin address. You don't have to think about expiry or anything like that, and so then moving into the Lightning context, it became more about, okay, we've got these Lightning invoices and they expire, but then people find other ways around that and using like, you know, Lightning address and LNURL and maybe in the future, Bolt 12, you know, so there's some of these different ideas around that, but I guess in this case, it You know, you're time-boxing it, maybe so that that server, that directory, doesn't have to like just kind of retain data for forever, right? And also, this, the, the theoretically, that transaction might go stale anyway, 'cause people might come and kind of propose a transaction and then go away and never actually do it, right? so I guess the other question I've got is around who would run a directory, right? Are you thinking of that similar to, you know, the people who run an Electrum server right now, or is it kind of like Have their, you know, their Raspiblitz or their Umbrel or something, and they can run a directory on that, and it's like an app they would install on their, you know, on their node. how-- who is gonna run directories and what's gonna be the model for that? Bitcoin transactions" }, { "speaker": "stephan_livera", "time": "31:03", "start": 1863.25, "text": "are small most of the time Think, how crappy an inscription image looks if you go look at some explorer for that. We're talking under ten kilobytes, so these aren't expensive servers to run and store this data for. 24 hours and they're one time use, so it's, it doesn't make a lot of sense to abuse this server to put a really crappy seven kilobyte image somewhere, that someone can only fetch once. if you communicate a key out of band, which you're already probably doing over encryption, like it just doesn't-- it's, it's low cost and it's only- Single purpose. So right now, payjoin.org is running one as part of the, the dev kit process, but I want to encourage anyone who wants to run one of these for their community Get in touch because it's, it's not crazy expensive to do. Yeah, I see. And so then as an example, anyone who wants a master relay or, VPN service might be interested in adding this as a sort of add-on to their product suite. And wallets, if they support Payjoin, want to make sure they have reliable- Directories, so they could either run one or perhaps partner with a, a secondary wallet to make sure one of them has this directory server running, the Payjoin directory running, and the other runs, an oblivious HTTP relay. So There's another issue I didn't mention directly, which is that if you're communicating with a third party server, that third party server is going to know your IP address. And in the past, we've used Tor or VPNs to communicate with them, but Tor is very heavy and VPNs are sort of optional. So there's this new tech coming out of, Cloudflare and Mozilla and Apple, that's related to Apple's Private Relay, which is a sort of one hop- Tor circuit, that can be used by default. So the only way you can communicate with this directory server is through an oblivious HTTP relay. It's eighty percent of the benefit of Tor with twenty percent of the effort, and you need both of those servers to be run by people in the community. So right now, some Some of the entities I mentioned before, I'm not gonna mention exactly who run the Oblivious HTTP relays, and I'm running the Payjoin directory, but the- Code is all open source, and I'm happy to help anyone else run one. We do need more of these things to be running." }, { "speaker": "stephan", "time": "33:43", "start": 2022.64, "text": "Yeah, interesting. And, it's interesting you mentioned Nostr as well, because there's a bunch of people who are thinking of Nostr as a way to sort of coordinate things. you know, I've heard of ideas like Joinstra and, you know, different ideas out there. and then presumably, I mean, it might-- we might get to a point in the future where in your wallet, some wallets have a setting where Have a manual Electrum server. Maybe you could, you could have like a manual, oh, here's my Payjoin directory, you know, here's my whatever that I would like to use, and, you know, that can be like a manual setting that people have, but maybe it has like some kind of safe defaults for the new user, right? In the same way that, like, I don't know, if you use like Sparrow today, it has some default Electrum servers in there, something like that." }, { "speaker": "stephan_livera", "time": "34:25", "start": 2064.57, "text": "The cool thing about the directory servers is that they're only getting encrypted blobs and With almost anything, it would be difficult to even conduct a timing attack, some intersection attack, they get so little information. So it, it's feasible that someone could run something like that. In their, in their wallet that just pops up." }, { "speaker": "stephan", "time": "34:48", "start": 2088.1, "text": "Yeah, really interesting. Okay. Well, that sounds great. while we're on the topic of V2 protocol, is there anything else you wanna mention in terms of Payjoin V2 versus the, V1?" }, { "speaker": "stephan_livera", "time": "34:59", "start": 2099.31, "text": "Yeah, I wanna touch back on Noster first. A lot of people want to use Noster for this because there are already relay servers all over the world. The issue with Noster is that it doesn't protect network privacy and it uses WebSocket. So because it uses WebSocket, you can't use something like Oblivion Oblivious HTTP and you would need to fall back on something like Tor, and that's really difficult to make a default. So the, the version two protocol focuses on two things. It really focuses on the one thing, which is to make Payjoin asynchronous, but to make that safe, we also need to have network privacy. So it includes this oblivious HTTP dependency. Now I mentioned some encryption and authentication, and that's all done using cryptographic primitives that are already even in core. So we get rid of transport layer security, web HTTPS, that thing. And replace it with something called hybrid pub key encryption. So like I said, you give me, if, if you're gonna request a payjoin from me, you give me your public key, and I have enough information just from that to derive the secret keys that we can use to communicate with, and we can encrypt payloads, and we can have authenticated payloads where we have a high degree of certainty that a certain payload came from the correct counterparty that had the keys. and because we use those cryptographic primitives that are in core, whereas TLS isn't, it's feasible to get something like this into Bitcoin core with Sufficient engineering effort, it's, it's possible that someone has a, an objection, but based strictly on dependencies, the spec is built to be compatible with the types of software that everyone using Bitcoin already has." }, { "speaker": "stephan", "time": "36:55", "start": 2214.71, "text": "Oh, cool, yeah, I, I wasn't aware about that. So, yeah, it's, pretty interesting then. It makes it, even more appealing, really. so- In terms of, other downside trade-offs or kind of who does it make sense for, if we're moving into a world, okay, maybe for now it's still kind of people can still do things on chain, but maybe over time it's gonna become more and more- You know, you're gonna need to be rich to be able to transacting on chain. and so does that mean, you know, the, the user, the user for this needs to be somebody who's got-- It needs to be a hot wallet, right? Like, that's the other trade-off, right? The, the-- Well, the reason-- Well, the reason--" }, { "speaker": "stephan_livera", "time": "37:36", "start": 2255.91, "text": "Why, why did it need to be a hot wallet? It needed to be a hot wallet in version one because the protocol was synchronous. So because when I sent you a request, you needed to get back to I can send you a request, you have twenty four hours to take your signing device out and sign a response and send it back to me, and then I can do the same. So the asyn- so the asynchronous nature really opens up the possibilities to improve the settlement layer." }, { "speaker": "stephan", "time": "38:06", "start": 2286.27, "text": "I see, okay. Yeah, well, that makes it definitely a lot more interesting. and so- I mean, it's still gonna not be as kind of practical as just kind of in, or like, let's say, in the old school way where people just kind of had one single address, there's no kind of, you're just paying that, but Maybe it would be like a batch operation thing, like maybe somebody is kind of collecting a bunch of these payjoin things, going away, signing them all, and, sending back. but in terms of who would, I guess, be the ideal user here? are you thinking just everyday users, merchants? do you have any ideas on that? Who would be the main users here?" }, { "speaker": "stephan_livera", "time": "38:48", "start": 2328.49, "text": "It is settlement more than payments, so it's people who are moving Bitcoin on chain regularly, and the people who do that the most are exchanges right now. Exchanges, maybe? Yeah. Yeah. So by offering this-- and this, it's important to also remember, this is the very first-- well, it's the second now, it's the second iteration of the sort of batching. We can do. I don't think we're limited to just two parties doing this, but it's a great way to start. This is-- The payjoin is the simplest form of batching the transaction structure itself. There are ways to batch with more, and exchanges are already doing this batching because it's inexpensive engineering effort relative to the, the benefit they gain. If an exchange receives a payjoin, they can use the cut-through mechanism I talked to earlier to receive a deposit and pay out a withdrawal in the same transaction. They can have the sender- Pay for their transaction fees. I think they stand the, the most to gain relative to the engineering effort, and once some payment processor has this, maybe some of these exchanges share payment processor infrastructure, like open, open infrastructure. And then also, anyone who's receiving Bitcoin on a regular basis on chain, whether it's a Lightning node operator or, you know, someone who's funded by grants, having this option gives you a way to optimize what you're posting to chain automatically in the background. You really don't have to mess around. The software can support it, and it can just take this Take their request. If it doesn't support Payjoin, you can just pay the person's address. If they do support Payjoin and they're online, you can make a Payjoin, and if it fails, you just get-- you're no worse off than you were before." }, { "speaker": "stephan_livera", "time": "40:41", "start": 2441.2, "text": "It's, it's, an optimistic interaction, and if it fails, you just fall back to the old ways." }, { "speaker": "stephan", "time": "40:48", "start": 2448.38, "text": "Yeah, that's really interesting. And so, I mean, people talk about the privacy aspect, but I mean, what you're talking about there is actually also really cool from a scaling perspective, right? Because you're kind of off-- to a limited extent, you're off-chain scaling because you're- You're skipping out transactions that would have otherwise hit the chain, and so you're kind of able to batch things in a really interesting way that kind of makes it more private and more scalable. So I think it's actually a pretty big win, from that perspective in terms of like just a fee savings perspective." }, { "speaker": "stephan_livera", "time": "41:21", "start": 2481.25, "text": "Yeah, I don't know how you've thought about, is, is the biggest, like, what is the biggest hurdle for wallet developers to have this? I think it is the correctness, like, ensuring you have this thing right, and then having a reason to do it, because you have to know that other people have also implemented it." }, { "speaker": "stephan", "time": "41:39", "start": 2499.22, "text": "Yeah, I think it's that, and if I had to, I mean, I'm not an expert myself, I, but I would say, if I had to guess, I think it's just that it's a whole new flow type, right? It's The reason that Lightning adoption wasn't like super high in the early days, and it's arguably not very high today, in certain communities and certain contexts it is high, but I think it's just like a whole new thing, and I think that's what maybe turned a lot of people off, or maybe it just felt like the UX hurdle, the u-- the user experience hurdle was just a bit higher. but I, I'm sort of thinking of V1, right? Like V2, actually, from what you're explaining to me, sounds a lot better. so, you know, It's more just about, yeah, maybe wallet developers, maybe aren't as aware about all the benefits. Hopefully they, hopefully they, you know, take another look." }, { "speaker": "stephan_livera", "time": "42:30", "start": 2549.84, "text": "Yeah, payjoin dot org is the executive summary, shows you kind of how it works, who supports it, what it takes, and it's being improved. Yeah." }, { "speaker": "stephan", "time": "42:40", "start": 2559.91, "text": "And, just out of curiosity, who supports it currently? Are there wallets that you know that already have, already using Payjoin DevKit?" }, { "speaker": "stephan_livera", "time": "42:48", "start": 2567.69, "text": "There are wallets using the Payjoin DevKit. So Bitmask and Mutiny both support sending Payjoins, the version one with the Payjoin DevKit. The version two is Only supported by our reference implementation right now, but there's an open PR to support it on Mutiny. So, Mutiny, you're listening to this, merge the PR." }, { "speaker": "stephan_livera", "time": "43:13", "start": 2592.96, "text": "The, the Payjoin CLI is, it lets you do this on Bitcoin D, of course. There's also some software for LND that was experimental that used this to let you open channels in a Payjoin, but it's not supported any longer. There are, there are around ten wallets total that support Payjoin, and the PDK, like I said, is used in those two. The other thing about version two is that it is backwards compatible with version one. So if you have a version two receiver and you're online, the version one sender will try to make a Payjoin with you and can succeed if you're online. If you're offline in the V2 case, you would just wait. If you're offline in the V1 case, it fails, but you at least have that. Optimistic interactive path available," }, { "speaker": "stephan", "time": "43:59", "start": 2639.46, "text": "with the V2. Gotcha. Yeah. and then I'm thinking, so as you've explained it, I think the exchange use case really makes a lot of sense there, right? Especially if they wanna start, you know, doing that cut-through stuff. maybe the harder part would be like if a merchant was gonna try to use this, because maybe now they've gotta start dealing, as an example, think about failure modes, right? If the customer pays the wrong amount or customer needs a refund refund or kind of, it just kind of, or the customer sort of tries it and they're worried that maybe the wallet didn't support it correctly or do it correctly. Maybe that's a concern, I don't know. I'm just thinking out loud. Is this" }, { "speaker": "stephan_livera", "time": "44:37", "start": 2676.85, "text": "different from correctness of implementation? This is related to the invoicing and- Like merchant specific user experience you're talking about, right?" }, { "speaker": "stephan", "time": "44:47", "start": 2687.0, "text": "Yeah, right. I'll give you another example, right? sometimes when you try to add new things into that same QR, the, you know, the QR codes, you know, the scanners, right? Like, so let's say if, if the user has like an older phone, maybe their, their, maybe their QR code won't, their, their reader won't read it as well. That's something I heard people say when you try, you know, in certain cases with, even like Bit Twenty One trying to In the one QR, to have like a unified QR, but it's a bigger QR, so now maybe certain devices won't be as good at scanning that kind of thing. Maybe it's, maybe it's related to that. I'm not, I'm not quite sure." }, { "speaker": "stephan_livera", "time": "45:25", "start": 2724.78, "text": "Yeah, I'm not sure we're going to know until we're talking to those users pay joining very frequently, which, since I've been speaking to merchant pay join users, their biggest- Gripe is that other people don't support it, and then most of the ones I've spoken to actually do most of their business over Lightning. So it's From the merchant, from the point of sale perspective, the payjoin is less important to them than maybe on their exchange side when they're doing settlements, when they're moving money, to buy inventory, that kind of thing." }, { "speaker": "stephan", "time": "46:01", "start": 2761.47, "text": "Yeah, it could be that. Like, I mean, it could just be-- I mean, and again, that comes back to what we were saying before about, look, on, in general, lower value commerce is gonna move to Lightning, right? So maybe Payjoin has a bigger impact for larger transactions, right? Like it just kind of, it's sort of obvious, right? So maybe that's where the focus has to be, But I mean, it, it-- there's a lot of cases where it might be handy for everyday users who are using an exchange, right? Even as an example, let's say you wanna-- you're an everyday user who has to sell some Bitcoin to pay your bills, and you're about to send some to the exchange. It would be cool to have Payjoin in that scenario, in that context, right? So let's say you're setting it up in your, whatever, in your Specter, your Sparrow, your Nunchuk, or Electrum or something, and if the exchange supported" }, { "speaker": "stephan", "time": "46:51", "start": 2810.98, "text": "At that point, if your wallet coordinates with them and you do a payjoin with an exchange, that could, that could be useful for you or it could be useful for the exchange too. Yeah, and then" }, { "speaker": "stephan_livera", "time": "47:01", "start": 2820.98, "text": "you get flagged by the exchange as someone who has this payjoin capability in their wallets, and they don't know what-- they don't know what to do looking at your, looking at your transactions, your other ones. They don't, they know, okay, this person can payjoin, but are-- is every transaction a payjoin? Yeah. And it also, it also does couple If I was gonna send you some Bitcoin and you knew you wanted a channel in advance, you could do that cut through to open that channel, or hopefully we can make it with splicing, it does seem possible to me. I, no one has implemented it yet, but it's feasible. So if you were to, you know Send you a payment that adds liquidity to your existing Lightning channel, it, it increases the value of that or removes it." }, { "speaker": "stephan", "time": "47:45", "start": 2864.96, "text": "Yeah, that could be really cool because then I'm saving on-chain fees myself, right? Like if I'm taking a payment and I wanna resize my Lightning channel up, I mean, that could be a really cool, example as well. So, you know, I think there's a lot of benefits to this, but it just seems like Maybe people either don't know about it or maybe the people who do know, I don't know, maybe they think it's too hard or it's not worth it yet. I'm not quite sure. But, I, I would like to see more people use this, to be honest. I think it would be a really cool thing. so, you know, let's see. so I think those are kind of the main questions I had. Any other, any, are there any other, I, I guess in terms of like, I guess you were touching on this as well, in terms of failure modes, you were kind of saying like basically it's just there's V2, and if it doesn't work, you fall back to V1, and that's Right, that's it, isn't it?" }, { "speaker": "stephan_livera", "time": "48:36", "start": 2916.35, "text": "Yeah, that requires, so if you try to make a payjoin to me, I have your original transaction that I can broadcast at any time. So if I don't broadcast that, you wanna send the transaction on your own, out of band, or it's kind of in limbo and this person can take that from you, whenever. There's another concern I think you had, which was, could someone probe my wallet for my UTXOs? So like, if I'm a receiver- And they make payjoin requests to me. are they trying to figure out what, what outputs I have that I opened? Yeah, yeah, yeah. Yeah. And I, I guess the answer is yes, but we have mechanisms to prevent this. So because someone's sending a receiver A payjoin proposal, a, an original PSBT has that spendable PSBT, the receiver can spend that at any time and get paid and, and not be super concerned. So there's a cost to, providing the response that includes your outputs. And then the other thing is, even if your counterparty knows your outputs, they'd know when you consolidate otherwise if you assume common input ownership heuristic holds, which it does right now. By and large, so we're no worse off by adding this payjoin functionality from that perspective of privacy, because the UTXO you would supply to consolidate would probably be consolidated later Anyhow, and when that consolidation happens, the cross input ownership heuristic would hold and, and you'd be broken. Gotcha. Yeah. Yeah." }, { "speaker": "stephan", "time": "50:18", "start": 3018.25, "text": "One other, I got, I've got two other ideas actually. One is, just around understanding the fees before the user broadcasts it, right? So in this case, let's say the user wants to do Payjoin v2, let's say you have it enabled, you've got the server, you've got the directory, et cetera, everything works okay, do I see the fees before I broadcast the transaction? Like, would that Maybe, now maybe that's on my side, on the wallet that I'm using to kind of show me that, is it, 'cause this, this might be a little bit hairy for some users, because maybe you're gonna, I'm gonna have to pay a little bit more than if I just didn't do a payjoin at all. Is that possible? but it's kind of like you have to think about the holistic long-term experience for that user and maybe consolidating his wallet is actually saving him in the long run, right? These decisions" }, { "speaker": "stephan_livera", "time": "51:04", "start": 3064.48, "text": "Can be made for the user by the wallet, made on behalf of the user by the wallet. Right. Yeah. with some strong opinions. Sure, a power user could get really nitty gritty and construct the PSPT themselves, but the only decision that a user really needs to make, and, Yashraj and I from the Bitcoin design community, built this document called the Payjoin Experience that goes through exactly this problem, where all of this, all a sender needs to do is pick a budget that they're willing to spend to make- make a transaction happen, which is the same as when you're spending a naive transaction now. You say, \"I wanna target a certain sats per byte, a certain confirmation time, and I'm willing to pay this much for it. \" And that's enough information for the sender and the receiver software to negotiate a payjoin. If the payjoin fails, typically that original transaction isn't gonna pay as much, and then if it succeeds You'll pay for the, one additional input from the sent, from the receiver. The receiver will pay for anything more than that. So if you did transaction cut through, if you added a whole bunch of inputs to a batch, the receiver would be expected to pay for that by, Custom and all that is checked on the sender software, so this can be completely abstracted away from a human looking at a phone." }, { "speaker": "stephan", "time": "52:23", "start": 3142.89, "text": "Gotcha, yeah. And basically, the-- Yeah, for, I guess for the everyday end user, it's kind of, don't worry, wallets are gonna handle all this in the background, and in practice As you were saying, if you're gonna add in all these inputs to the transaction, I guess the convention, the custom would be, well, if you're gonna add all these inputs, you should pay for it, kind of thing. Like you pay for it out of your side, not put that onto, let's say, the customer side or the sender side." }, { "speaker": "stephan_livera", "time": "52:48", "start": 3167.74, "text": "And the software By default enforces that. You could write custom software that breaks that, but it's, it's kind of like policy in Bitcoin, right, where if everyone's following this, things just kind of work smoothly, and if not, you get an error message and that's fine, you can still send a regular transaction if the person doesn't want the payjoin, because just adding one input isn't that expensive relative to the complete size of the transaction we're talking about. Maybe twenty percent of the total transaction cost in, in the worst case." }, { "speaker": "stephan", "time": "53:18", "start": 3198.18, "text": "Another area that, has been interesting to me recently is silent payments as an example. So I'm actually gonna be getting those guys on, soon as well for an episode about that. But I'm curious if you have any thoughts on what other technologies, privacy techniques could help from a privacy perspective, right? Like, I mean, the reason-- Let me just explain the silent payments case. The idea is you could have like a Bitcoin user Name, and you just kind of take payments to that, and you're giving the, the outside chain surveillance person less of a starting point, right? Because historically, if you just had a public Bitcoin address, then they kind of know where to start, right? They kind of know, oh, I start from this address and I trace it out. But as an example, like hypothetically, imagine we had broad adoption of silent payments, and we also had broad adoption of Payjoin That would probably already, just those two pieces, you know, if it was broadly adopted, could really move the needle in terms of Bitcoin privacy, in terms of at least not being apparent on chain to outside observers." }, { "speaker": "stephan_livera", "time": "54:20", "start": 3260.25, "text": "Yeah, they're both systemic updates to the way everyone uses the system. They provide a lot of help, but we do need to get the wallets to- To integrate them, you could use a silent payment with a public Payjoin address with some tweaks to the way things were expired. I'm so stoked to see them have the success they're having getting into a couple wallets now, people using them. And they went a slightly different direction, they solved a different problem, but they got rid of interaction for compute, and I think that's-- if you can do that anytime, you wanna make that decision. Yeah. Going" }, { "speaker": "stephan", "time": "54:56", "start": 3296.02, "text": "beyond-- So I guess just broadly, yeah, do you have any other ideas in terms of what other pieces would help from a privacy perspective? Yeah," }, { "speaker": "stephan_livera", "time": "55:02", "start": 3302.39, "text": "going beyond that, I think we really- Need to look at how to get differential sort of privacy on, on Bitcoin. we've been in this anonymity set mode of thinking for a long time, which Comes from academic research about privacy of networks, like information sent over a network in relation to mixnets, but with Bitcoin There's so much state that is permanent and there's values associated with the state, it's a big database, and I, I guess differential privacy is where you jumble the The database itself so that if one person's information is discovered, it doesn't, it doesn't de-anonymize the other people. This is what's used for census information, for example. So this is really standard Privacy, approach when a lot of people's public information is, is at stake, and we can achieve that on Bitcoin probably by creating these batched database updates, which is what- The CoinJoin, CoinJoin techniques are generally, but rather than have it be this manual process where people want to get privacy, really preserve their privacy, against an adversary, to only selectively reveal themselves Like that's just expensive, it makes a lot more sense if we can batch our payments that we're making anyway because we have this cost savings associated, and then Payjoin's the simplest way with two people It should be possible to have more than two people come together to make one of these batched payments to both save money and then get privacy. there's one other point about the types of privacy I wanna mention. So when we think of CoinJoin, Chameleon, CoinJoin, Blind Signature, CoinJoin, Anonymous Credential, CoinJoin, Privacy, we're talking about a few people get together, they put- some Bitcoin into this coin join and they get some Bitcoin out that's approximately the same amount minus fees, but their output is indistinguishable from everyone else's output, so they have privacy from the second party to the transaction. They have privacy from every other person that participated in that and the coordinator, they don't know what output they have. They also have third person privacy where a dragnet, someone who didn't participate, doesn't know what happened. Payjoin only has this third person privacy property, where it creates this indistinguishability between a regular payment and a, a payjoin for a third person onlooker. But if you and I are both participating to the payjoin, we know exactly what happened inside that. When we add a third or nth person To a payjoin, we can get rid of that second person privacy leak while having these other benefits of payjoin, but it's a matter of-- at least the way I've conceived of it now, it's a matter of interaction. Perhaps we can come up with An asynchronous way to depend on more compute instead of, interaction, that would be amazing." }, { "speaker": "stephan", "time": "58:27", "start": 3507.28, "text": "Interesting, yeah. And so in a way The, in that multi, let's say more than two person model, it, does the directory become kind of like a coinjoin coordinator in a sense, like a pay, being a payjoin coordinator sort of?" }, { "speaker": "stephan_livera", "time": "58:41", "start": 3521.26, "text": "It could, I don't know, I don't know if you would just rely on the directory or you would be able to have some other peer-to-peer protocol or you would need a broadcast network where I can send messages to a group of people I know beforehand and I can reliably recognize whether they got it or not. we probably need some, we probably need mo-both broadcast and pairwise communication because if you and I are both participating in this multi-party payjoin And I pay you some money, but I don't know what output you actually get or what outputs you get, then I need some confirmation from you authenticated that this is from Stephan and he definitely got paid because I don't know anything other than that, in the transaction. That's the ideal. So, yeah, so there's maybe a bit less" }, { "speaker": "stephan", "time": "59:25", "start": 3564.83, "text": "certainty. You don't know my inputs," }, { "speaker": "stephan_livera", "time": "59:27", "start": 3566.65, "text": "I don't know your outputs, I just know that you got paid what you asked for." }, { "speaker": "stephan", "time": "59:30", "start": 3570.5, "text": "Right, yeah. So it's kind of like, how Rusty from, you know, Blockstream talks about proof of payment, right? He was really keen on having this proof of payment concept. so, yeah, really interesting stuff. So look, I think, that's probably a good spot to wrap up here. So I'll just summarize. Payjoin is this technique that could improve privacy and scalability in terms of Bitcoin's, you know, transactions. There's a Payjoin Dev Kit that wallet developers can use. It's a library that they can use to integrate Payjoin into their wallets, and, yeah, it'd be great if more people, you know, get into this, start using it. I, you know, I think it would, it'd be really cool to see. So, everyone, follow, Dan and find the website again is payjoindevkit dot org. Dan, thank you for joining me today. Thanks, Stephan. I hope you enjoyed the show. If you did" }, { "speaker": "stephan", "time": "01:00:24", "start": 3624.34, "text": "Check out my website at stephanlivera dot com, and I will see you in the citadels." } ] }