TFTC: A Bitcoin Podcast - #431: Bitcoin Privacy and the Payjoin Dev Kit with Dan Gould

Episode Date: July 5, 2023

Marty sits down with Dan Gould to discuss Payjoin Dev Kit, how coinjoins protect privacy, and the experience of developing on Bitcoin. Dan on Twitter: https://twitter.com/bitgould Payjoin Dev Kit: https://payjoindevkit.org/ 9:16 - Dan’s history 14:39 - Explaining CoinJoins 21:36 - How Payjoin reduces dox threat and reduces fees 35:09 - TURN servers 39:49 - How are PSBTs involved in Payjoin 42:45 - How coin selection is determined 36:30 - Separating PDK from BDK 50:03 - Completing BDK 53:38 - Payjoin’s role going forward 57:54 - Chain surveillance and prosecuting CoinJoins 1:03:51 - Right to privacy 1:08:18 - Multi receiver PayJoin 1:09:42 - Less frustration on Bitcoin development 1:15:18 - Will Bitcoin reach sufficient ossification? 1:18:25 - Plugs and wrapping Shoutout to our sponsors: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Unchained⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠River⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠CrowdHealth⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Bitcoin Talent Co⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ TFTC Merch is Available: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Shop Now⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ Join the TFTC Movement: Main ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠YT Channel⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ Clips ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠YT Channel⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Website⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Twitter⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Instagram⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ Follow Marty Bent: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Twitter⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Newsletter⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Podcast⁠⁠⁠⁠

rolling logan what do you think about this studio it's beautiful it's this nice got plastic color what about the background noise does that annoy you it's a doesn't have any helicopter noises right now no not right now fourth of july weekend here the jersey shore We're not too far away from the Atlantic City airbase. There's a lot of military aviation devices flying around. So please forgive me if they make any noise.

While we do this intro, I just sat down with Dan Gold, who's working on a pay join development kit. I think it's an extremely important project in the space that is very underappreciated right now. hopefully becomes more appreciated and hopefully this episode gets you to appreciate it because being able to transact with sufficient privacy assurances on the bitcoin network is going to be really important for driving adoption that's something dan is really passionate about and is working to make available to everybody so i hope you guys enjoy this rip uh and support the project if you can in any way you can simplest way you can do it is just make people aware of it that is being worked on and that wallets and exchanges should implement it into their stacks uh before

we get to these sponsors we have to read some boost it's been a while been traveling a lot haven't been able to read boost for past shows so we'll start with 428 examining blackrock's etf with towns and lansing from coin shares at paez 25 000 sets the signal is strong this is the way i agree pious thank you for the boost and guess what pious gave us another boost 3 000 sats had to boost again to bump tftc into the top 10 thank you pious at joel w mark my words those black rock demons have a plan to break bitcoin your words have been marked joel they've been marked in my brain i will remember them if black rock tries to break bitcoin i doubt they will be able to though and then at nano moto 1000 sats shit coiner that's not nice that's not nice

nano moto those are the top four reps for 428 with towns and lansing we're going to move to rip 429 the inflation is the inflation problem really solved with luke grumman another great episode with luke love that dude really starting to grok bitcoin and the impacts it will have on the energy sector, particularly the mining industry. At Eric99, 50,000 sats. Stay humble, stack sats. Thank you, Eric. Great advice. At user 7018927165642016. Marty, aka Larry Lonin. Lonin? Yonin? Y-L-O-N-E-N? How would you pronounce that, Logan? what was it lauren lauren i'll just go with that when when can we acknowledge simply bitcoin is just a ripoff of you and odell no one no disrespect to them guys i still listen to

them some similarities are just a bit too uncanny anywho someone needs to tell crowd health bmi isn't a suitable metric anymore it could be perceived as racist if they continue to use it Lastly, Odell, stay humble and stack sats is great advice, although I hear that more often than adolescent girls say like in between every other word they use. I like the SimplyBitcoin guys. I think they're doing a great job. That's all I'll say to that. At BlockchainBug, 5,000 sats. Clap, clap.

Wage shortage, which drives the labor shortage. Very important. At Nanomoto, 1,000 sats. It's totally going to ship trucks of gold around again instead of 60 minute six block confirms regard traders. Nanomoto, just like you're in the top four booths for the last two episodes. A lot of negativity, man. Can't have negativity in your life. If you're looking for some positivity in your life, you should check out River.

River is a Bitcoin company that is doing it the right way. They build their own infrastructure. They own their exchange. They own their wallet infrastructure. sure they built their own uh lightning network api that anybody can leverage river lightning services they have mining as well but if you want to simply dca into bitcoin uh sign up with an account at river use river.com slash tftc get set up if you set up dollar cost averaging you're not going to pay any fees on those buys set it and forget it again river has taken the long and hard

path of building everything within their company so don't have any third-party dependencies they were completely unbothered by the prime trust debacle that has been going on uh and this is why i'm very proud that they are sponsors of this show because i think they're doing it the right way so if you haven't tried out river yet go to river.com slash tftc and sign up today this was also brought to you by good friends at unchained another company doing it the right way also completely unbothered by the prime trust debacle going on they leverage bitcoin's native multi-sig properties to give you custody solutions and then financial products on top of that custody they have their vault product which is two or three multi-sig which helps you eliminate single

points of failure in your custody model it gives you full control of your bitcoin as long as you have those two keys you control two keys unchained has one if you only have one key for a reason and you need unchained to be the second the two or three multi-sig quorum they are there for you they have a lending desk that leverages multi-institution multi-sig you put up bitcoin as collateral in a two or three multi-sig you hold a key unchained holds a key and kingdom trust holds a key uh since you have a key in that quorum you have visibility into your collateral no it's not being re-hypothecated as long as you're paying that loan back plus the interest you're going to get your bitcoin back at the end of the day you can audit that uh go check them out go to

unchained.com slash consultation if you don't have your bitcoin off an exchange in its self-custody Unchained is one of the best ways to take self-custody and to have peace of mind with your security setup. You don't have to ape into the product. It's just go set up a consultation, talk to their team, go to unchained.com slash consultation, tell them the TFTC sent you. This report was also brought to you by your friends at CrowdHealth. CrowdHealth is here to help you reimagine healthcare. It's a crowdfunded model. It's not health insurance. Health insurance is notoriously opaque, expensive, and impersonal. CrowdHealth is changing that.

You pay a monthly fee, and if you ever have a medical expense, you go to the doctor. You tell CrowdHealth, hey, I'm going to go to the doctor. They can help you find a doctor if you need one. You go to the doctor. You get the bill. You bring it to CrowdHealth. They talk to the doctor directly, negotiate the price lower. You pay the first $500 of that bill, and then the rest gets crowdfunded by the community.

And they've had 100% of bills paid to date. can't guarantee that but the model seems to be working very well also health crowd health has a healthier community uh which lowers the overall health care cost for you as an individual you have to pay into it's a great product great ux me and my family use it if you're on cobra right now if you've been recently laid off and you want uh some health care cost coverage go to join crowdhealth.com slash tftc last but not least this rip was brought to you by good friends of Bitcoin Talent Co. They are a recruiting firm built by Bitcoiners for Bitcoiners. If you're talent looking to get into the space, you're in the tech sector, the banking sector, fintech,

whatever it may be, you feel like you're working a fiat job, you want to get into the Bitcoin ecosystem and the Bitcoin industry and build out the Bitcoin standard, go to bitcointalent.co, get a profile set up, tell them the TFTC sent you. And likewise, if you're a company looking for the best talent in the world get hooked up with bitcoin talent co as well uh again built by bitcoiners for bitcoiners they understand uh multi-sig they understand lightning they understand mining they can help you hire the right people they're not just some run-of-the-mill recruiting firm that's sort of shooting blind looking for bitcoin talent they know what they're doing the co-founder andy built out the team at uh uber took it from like less than 100 people to 10 000 people

He knows what he's doing. Go to BitcoinTalents.co. Tell him that TFTC sent you and enjoy this rip with Dan Gould. Take care. themselves to devalue their currency bitcoin wins in the world of fiat currencies bitcoin is the victor i mean that's part of the bull case for bitcoin if you're not paying attention you probably should be probably should be we're going dan gould welcome to the show thanks for having me marty well thanks for joining i'm very excited about what you're working on you recently released the pay join development kit to make it easier to integrate pay joins into bitcoin wallet software

just bitcoin projects in general and pay join is something pay join pay to endpoint whatever you want to call it is something i've been writing about in the bent for at least four years now and something that we've talked about on rabbit hole recap and tfdc many times throughout the year the years and i think it's something that's very important but for some reason or another It hasn't got a lot of adoption since it's been available to people. So I guess before we jump into PayJoin and the development kit that you're building, why don't we learn a little bit about you, your history in Bitcoin, and why you decided to focus on this one area, PayJoin specifically.

Sure thing. I started in Bitcoin development in late 2016. I was really fortunate. So I found Bitcoin on the internet and interested in it as money, of course, as we all are. And when I was in college, I found TumbleBit on Reddit and looked at the byline, which was Ethan Haleman. So TumbleBit is one of these privacy protocols, early days, 2016. And Ethan at the time was my teaching assistant. He was the teaching assistant for my probabilities class.

so my mind was just totally blown that like real people actually worked on this stuff that i could go talk to so during winter break i had the opportunity to go into the lab and work on tumblebit i really wanted to contribute to open source and bitcoin captivated my attention and i just made a really crappy pr uh to change configuration settings on that and that turned into this whole journey down the rabbit hole and multiple open source projects and focus on Bitcoin privacy. So from there, we went to Stratus in the UK. They wanted to implement Tumblebit, but this was before the 2019 FinCEN guidance on what

you can and can't do with Bitcoin privacy. So that kind of ties into what's going on with Arc now and which privacy protocols work and don't work. So out of that group that was working on Tumblebit came Wasabi and Nicholas went on, he was working on that too and he went on to work on BTC Pay. So I was traveling at the time and using iOS for Bitcoin and was really disappointed I I couldn't use Wasabi for that. So I forked Wasabi into Chaincase,

which is an iOS app that does some coin joins. Kept thinking, okay, does this really solve the problem? Does this really solve the problem? I don't think the application level solves the problem, doing it in an iOS app. I don't think iOS users are the reason we don't have Bitcoin privacy is what it comes down to. So started collaborating with some of those developers

that were working on Wabi Sabi and looking at it more from a systems perspective when I realized PayJoin is a really simple protocol that gives you reasonable privacy and it's incredibly convenient because it works just like a naive Bitcoin transaction would from a user's perspective and started learning Rust

and that turned into the PayJoin dev kit. And the point of that is that rather than create a piece of wallet software that has privacy let's just bring privacy by default to all of the bitcoin software and services that exist yeah and you mentioned uh fincen guidelines that were clarified in 2019 what what did those guidelines say explicitly like what what type of structure did that give builders so i don't have it directly in front of me and i'm not a lawyer but the overarching theme was if you're not able to unilaterally spend someone's money then you're

not a money service business which means you don't need to apply for licenses and it means you're a networking business so you can run a regular software company and be a transaction coordinator like a atomic swap coordinator or a coin join coordinator and you're in compliance with the law so that let all sorts of privacy innovations happen as long as you don't have that custody of user funds which is awesome because it means that users can get this help from the cloud if you want to call it that and their clients can still have really excellent privacy guarantees so let's take like a broader view on this just like coin join more generally as sort of a transaction type to to create better privacy assurances for users as

they transact on the network that's i mean i'm sure many people have listened to tftc and rabbit a little recap understand coin joins quite a bit but for anybody maybe new to the show what is a coin joint how have uh implementations like join market wasabi and samurai implemented it to date and how does pay join differ in the way that they're doing it yeah i was listening to you and matt on rhr yesterday get into a little bit of how pay join might be a complement to these things and it's not a replacement per se so when we're talking about bitcoin transactions we know that those transactions don't come from accounts your bitcoin wallet isn't so much an account as it is a collection of keys that can spend entries in the bitcoin ledger because anytime someone

pays you, they're making a transaction and you get an output that your key can unlock. So because it's not accounts, you have some pseudonymity, but there are naive ways that most wallets will spend Bitcoin. And when you do that, it's very easy to track all of your behavior, your balances, and you can put a target on your back, which is dangerous if someone wants your Bitcoin. So CoinJoin fixed that problem partially by having multiple people come together and make equal outputs at the same time so that someone looking through the history comes to a CoinJoin and they're not sure which one of those equal outputs belongs to you or the other participants in the coin join.

There's a whole boatload of caveats about how you spend after that can deteriorate that privacy. But in general, if you look at the one coin join, the idea is that all of the participants have forward-looking privacy, meaning once someone gets tracking back to that coin join,

everything in front of that is unrelated to everything behind that. yeah and you mentioned this in the uh the blog post announcing uh pdk which is essentially what coin joins are trying to do it's funny because you're using an output as an input in a new transaction and so by doing a coin join you're essentially corrupting the common input ownership heuristic used by chain surveillance companies that try to track you across the ledger so if you buy from an exchange and send to a wallet the wallet basically uses that common input ownership heuristic to assume that you control that wallet and then as you spend forward in time from there

you sort of use that to track you and so coin join sort of corrupts this heuristic correct coin join corrupts the heuristic and also because you have equal amounts which is how join market wasabi and samurai operate you have not only ambiguity in where the inputs came from like did they all come from the same user or not but you also have that multiplied by a number of people that participate so your coin becomes one of all of the participants in the coin join and then assuming the implementation is done cleanly the rest of all of the other people who do coin joins that spend from your source coin join as it relates to join market join market school because there's not fixed output amounts so you can make a payment of your specified amount and then all of

the peers that join you in that coin join you pay them to participate and they make your decided equal amount which is great because it's kind of like a paid join and that you spend and you don't have to worry after that you have this change amount because you're making equal amounts with a coin join you end up with this change amount that's still linked to the original history and wasabi and samurai at least wasabi version one just do something slightly different where everyone has the same output amount so everyone gets change and wabi-sabi with wasabi v2 try to fix this by allowing any, not necessarily any amounts, but they break down the amounts in the outputs based on the input to try to reduce the amount of change.

But all of these still suffer from some, both the knowledge that you know that it's a, what's called a mix, meaning all of the inputs and all of the outputs are the paying themselves. and with join market you have all of those other takers who took the maker's payment amount they don't have an incentive to keep that new amount their incentive is to join more join market transactions so you can kind of figure out who made the payment and who was a maker down the line there's not a ton of protection from that and in wasabi 2 even though you create all of these different amounts the person who put the greatest input still has the greatest output set so you can do it's computationally expensive but if someone

were targeted you could still target one of those participants and figure out a likely set of their outputs and over time break that down samurai tries to stay to the zero link everyone has the same amount everyone has these same spending conditions which you still get that change that their solution is just never spend the change or some people use swap services and stuff which is expensive but really i think the key point is that they all still have this change problem whether they say it or not and you don't have assurances for arbitrary amounts that your inputs and outputs are unlinked and the if you do multiple inputs the inputs are unlinked and if you have multiple outputs the outputs are unlinked and this is where pay join really uh makes a difference pay join

because you have a payment amount you have the potential to break all of those links you're not depending on the equal output amount you have a potential to get rid of all of it because you're making no change yeah that seems pretty massive because the change that you mentioned is commonly referred to as doxic change uh in the community because it's toxic to an extent because it can dox you if you co-mingle that that change with an output produced um while you're coin joining or at the end of the coin join and yeah so like let's dive into how pay join really reduces or reduces that threat of the docs exchange because it's a really cool way and if you're successful when you are successful it's that confident here and uh getting pdk to the point where it

can easily be implemented in many wallets like the ideal scenario is that you're just spending and doing pay joins as you spend um and just unknowingly increasing your your anonymity set as you spend your your bitcoin maybe not your anonymity set but your you have better privacy insurance as you're spending anonymity set is a really interesting thing to talk about though because that really comes from mcnets mixnets that comes from network privacy back in the early This paper came out where they're working on anonymizing network traffic and network traffic doesn't have an amount associated with it really. Network traffic is just packets. And so if you have an anonymity set of people browsing the internet, for example, that's the number of people that the traffic could potentially originate from. With Bitcoin, at least with Chamian coinjoins, with zero-link coinjoins, this idea has been borrowed and adopted. So if everyone has the same amounts, we can think of this anonymity set in isolation in one transaction.

But it kind of breaks down when you look across a bunch of transactions with this doxic change problem. So I don't think it's a harm. Like, I'm glad we are using some sort of measure, but I think it's imperfect. And when I think of page one, I don't really think of anonymity sets so much as ambiguous interpretations. Like, how many interpretations could you imagine a certain output has? How many people, it is how many people this could have come from, but also, like, how many different trees of transactions, how many different histories is this associated with? and because you don't have those equal amounts because you're paying someone so pay join is just two people at least in its current iteration pay join bip 78 pay join is when a sender and receiver

combine two transactions into one you have the sender wants some privacy and the receiver is open to consolidating some of those outputs together so they spend fewer outputs when they spend later on because they contribute input to the transaction with the sender they consolidate what would otherwise be two outputs their previous output and their incoming payment from the sender into one and the payment amount because it's combined is hidden it's not explicit on the chain the payment amount is the old input from the receiver plus the payment and some change and you can set up the input amounts and the output amounts so that someone looking both doesn't know it's a pay join and they also

don't know which one of the outputs includes a payment yeah and that's again pretty massive if it can become widely used and popular and i guess is a good good point to jump into why it hasn't received as much as that adoption as many people like myself would like and i imagine that revolves around the need for the receiver who needs to put up an input with the sender to have essentially a hot wallet and an always-on server that enables them to essentially create inputs in these pay join transactions yeah having a hot wallet to always contribute an input and being available all the time to add that are definitely the biggest barriers but i think we can get around both of them so because you're contributing an input

right now you need to have a server that's online that receives a proposal and can respond with an updated pay join and this is kind of similar to coin join where everyone that's participating is online and talking to a central server to figure out everybody else's intent pay join pip 78 pay join pay join v1 solves this by having the receiver run a http server that you can make those requests to and it can respond to which is great because http is everywhere We're using HTTP to have this call right now. It's ubiquitous versus something like CoinJoin, which is a custom protocol that you need a whole network stack

in your app to use. So you need kind of custom apps. It's a huge dependency to add. The only application besides a CoinJoin-specific app that has this, as far as I know, is, well, there are two. It was BTC Pay Server and Sparrow. there are like different versions of some of the coin join apps but most of them are just coin join apps uh because there's an incentive though for the coordinator i think coin join

has been able to skirt around this they've been able to get teams together they've been able to raise money and they've been able to deploy these standalone wallet apps because there's that incentive where okay if we deploy this we're going to make a lot of money and everyone wants to make money versus pay join. There is a small incentive for the sender who gets privacy and the receiver who can do that consolidation, basically batching to save fees later on. But that hasn't really been enough to convince companies to take it on because it's difficult. There hasn't been any library software to do it. And I don't think anyone had explored before recently what that idea of batching that can be done with CoinJoin really does.

There's this whole idea of transaction cut-through that Greg Maxwell came up way back in the day where if multiple people propose transaction intents before they post them and they can interact, then you can get rid of some steps in a transaction process which gives you privacy like how PayJoin gets rid of the payment amount. And you can also do a lot of cool stuff by reducing the number of steps it takes to open a lightning channel or even for services to batch transactions that are incoming.

Instead of just batching a bunch of withdrawals, you can do those and also pay them with incoming sats without ever having to take those sats into custody first. There's like a whole unexplored territory. So, yeah, basically we removed that hot wallet and server requirement through something. There are a bunch of tricks we can use to do that, but also I think telling the story of how this fee savings can be so great could also really help pay joint adoption. So these are all on the roadmap and mentioned in the blog post, but it has been a real difficulty. Yeah. I mean, and the fee saving thing was, you mentioned that you listen to Matt and I discuss this on Rabbit Hole Recap, and you mentioned it in the blog post too. Is it really only fee saving for transactions like Lightning channel openings? Or does it go beyond that for other use cases as well? It goes beyond that for other use cases.

So the Lightning one is probably the easiest one to understand because it gets rid of a whole transaction in a typical flow. To understand this, we've got to go into the Lightning funding transaction flow. So let's say your buddy sends you some sats in a UTXO on-chain and you want to open a Lightning channel. You would have to send those sats to your Lightning node, wait for a confirmation, and then propose a channel open. open another transaction with a Lightning peer. With pay join, because

it's interactive, you can propose to send some sats to your Lightning node, like your buddy who pays you, and the response can include an output that is the channel open with your peer. It can just replace that original intent. So the only transaction that actually gets posted is funded by your buddy and opens a lightning channel this is like without even channel batching this is just you skip a whole transaction but you can also batch transactions with that that's the idea of transaction cut through does that make sense yeah yeah and so yeah you're essentially cutting one step out of the lightning channel setup process because if you're opening a channel in the first place you're going to want

two-way liquidity um so you would have made that transaction anyway correct yeah you would always need to open you always need a new output that's the channel output so either you take a single sig into your own custody first or you get rid of that step by communicating with networking instead of communicating using the chain and this is the idea isn't limited to lightning channels that could be used for an exchange too like an exchange could queue up a withdrawal say one of the users wants to take sats out of the exchange they could say that and the exchange could say okay that's going to happen sometime during the day and if they get a pay join coming in rather than putting those sats coming into the exchange

into the exchange's address they can just put those sats directly into their withdrawal and take the XSS change into the exchange because the pay join proposal includes like a fallback transaction that doesn't have to necessarily get posted. That can always be updated with any number of payments to a withdrawal or say they wanted to pay a bill or they wanted to open lightning channels. You can really extend this cut through idea quite a bit where both sides can now be batched instead of just an exchange batching a bunch of withdrawals they can also batch their inputs funding withdrawals which is a huge problem when the block space market becomes expensive a lot of the times exchanges just run out of utxos that aren't confirmed to pay withdrawals

yeah i mean that's massive i mean you can make the argument like this is a great way to reduce the amount of times it's necessary to touch the chain for service providers, whether they're running a lightning company or an exchange. Is this why, after I posted that newsletter earlier this week, Francis was getting all excited, thinking, is that how he's thinking about implementing it in Bold Bitcoin? Yeah, he really gets it.

He's gotten it for a long time. But, like, there hasn't been a pay join receiver that works with their Cypher node backend, you know? there's been the btc pay server one but there hasn't been any way to connect it to bitcoin d or connect it to lnd and that's what pdk allows that's really that's what improves it more than anything else um we do need and it's great for an exchange because they're running a server all the time anyway there's definitely a way to get rid of that server requirement um or have someone else run a server for you kind of like how offline lightning payments would work it's very similar

but for someone like an exchange as long as you have the software that works it is a great cost saving thing and the other thing matt mentioned was the difficulty of sending a transaction the cool thing is payjoin version one was engineered around the bitcoin uri standard so the experience from a user's end is the same if the wallet supports it it'll just send payjoin And when you scan the QR or tap NFC or paste the URI, there's no, you don't have to put your funds into Lightning and then use Lightning. You don't have to put your funds into a CoinJoin app and then use CoinJoin. It just works. So the receiver essentially would initiate it and the end user may not even know that they're engaged in a pay join unless they are hyper-cognizant of fees.

Is that correct? Right. The receiver adds a little more data to the address they would post anyway, and the sender's wallet, if it supports it, can use that and otherwise can just ignore it. Yeah. This is fascinating. And so turning back to the server, which is really interesting, you posted on the Bitcoin dev mailing list earlier this year, I believe in January, my memory serves me correctly here about solving this always on server for the receiver problem with something called a turn server a turn relay what is what is this concept yeah i think linking to that uh mailing list might cause some confusion because that was like the first version of it

where i put it on the mailing list to see if there was interest in the idea or not uh a turn is is a very old way of getting two servers that are two computers that don't host servers to talk to each other using a relay. So this is assuming they're on all the time and the receiver negotiates with a relay. And then that relay, if the sender connects to that relay, the relay can talk to the receiver. I don't necessarily think this is the best way to go forward because there's there's actually huge improvements and relays over the past couple of years like noster obviously we relay media and that gets around censorship in a huge way but also there's these two things there's two pieces of technology one is called oblivious http which is kind of like tor without

all the complexity of a consensus network and this idea called mask which is like turn reimagined it's a much easier way to do a relay server and both of these are supported by ios 17 and they're advertised as privacy features so turn is like complex and a lot already supports it but the cool thing about having ohgp and mask in operating systems is that we can again use this pay join dev kit in all these different wallets and expect that these relay softwares will already exist so i'm not like sold on turn turn is one way of having a relay and that at that time was a good way to understand for me to put into words that we're going to use a relay to get rid of the requirement to run a server but it could be

any number of different relay tech it could be monster you could do that that would be fascinating if you could just like dive deeper into this like what is leveraging this type of relay infrastructure regardless of which one it ends up being like why does it make it easier well i think we should settle on one relay in a standard because then all the software can talk to all the other software when we're saying just put a relay here no one adopts it no one has interoperability and that's kind of what we have now in the original bib 78 there's actually this idea of an unsecured pay join server where you make a pay join using a relay but that relay is trusted not to share your information

they can still see stuff and stowaway in samurai and sparrow also does relayed pay joins but through Tor and without a public specification that was built using a collaborative process. So it's just really hard for wallets to use those technologies because they need to build something proprietary that like an exchange could do it between their exchange app and their exchange. But beyond that, it would be really difficult to actually roll out. And the idea of serverless pay join would be to come up with a standard that all different wallets could implement.

And I think a mask is probably the best way to do that right now. You create an application that the specific pay join relay understands and it's well specified. So any client that wants to do serverless pay join, relayed pay join, whatever it ends up being called, can agree that, okay, we can talk over this relay and we're going to have encryption so that the server can't snoop. And some other, you can set some other requirements so that the server can't even do timing attacks. And that's why it's serverless, because you're not running a server and you're not really depending on, you're not trusting someone with your privacy. Yeah, I completely agree. You know, standardization and coming to agreement on what the relay is going to be that everybody uses is very important. um and it's been encouraging to see like standards around like psbts get adopted by the

by wallets too um which is i was actually talking to rob hamilton earlier today and told him i was going to be discussing this with you and whether or not he had a question for you and it was revolved around like psbts like how if at all are psbts involved in pay join or this infrastructure before i ask that question i want to uh say one thing about relays which is oh people don't think about relays but we use them all the time and one of the standards that uses one that has just blown up is ln url ln url uses a relay so you can get a invoice whenever you want and that one has just been huge for lightning adoption and making it possible for people to receive without running a server all the time or being able to dedicate to

a different service but as far as rob's question psbts the page one protocol is really only two things it's it's an interactive psbt coordinator and then it's the specific network packets that you send back and forth to agree on fees and prevent attacks it's those two things psbt coordination and networking. The protocol is so simple, I can really just explain it in three steps. So the first step is you generate that address that includes your server URL. This is your Bitcoin URI with a pay join parameter. That's the receiver does that. Then the sender constructs a transaction as they would normally. I call this the fallback transaction that pays to the address the receiver sends but instead of just broadcasting that transaction they create a

complete valid psbt and they send that to the receiver's server that they specified so the receiver gets that and if nothing else happens they can always broadcast that transaction they always have valid money that's going to pay for whatever service so because they have that they're comfortable contributing inputs that the sender might not know about and returning a new PSBT with their inputs and the outputs change to include the value of that input. So it's really two PSBT's that get sent back and forth and that's it.

Yeah. And as you're describing that process, how long does that take? uh it's basically instant it's just like sending a message sorry i'm gonna plug in my computer here i don't know what happened i unplugged it stepped on it it's uh yeah that's that's the whole thing is it just takes as long as it sends as it takes to send a text message as long as the server is online you send a message and they respond and so like with that instantaneous interaction there it's like me driving my mind towards like how does the coin selection work on the receiver side

in terms of UTXOs they're providing as the inputs? Is it random? Obviously, it's a hot wallet. They'll put particular UTXOs there. Is there like a coin selection algorithm in the background? This is another thing PDK does that other implementations haven't. Until I think earlier this year, BDK was, sorry, not BDK, BTC Pay Server was, it wasn't picking random,

but it was creating transactions that could sometimes be identified as possibly pay joins. So there's this thing called unnecessary input heuristic, where you're putting more inputs into the transaction that are strictly necessary to create one of the outputs that's assumed to be the payment output. And there are different varieties of this. Some of them are identifiable as pay joins,

some of them not. So the receiver does have to be cognizant of which inputs they choose. And the PDK has a function that you can just call on your inputs that will construct a pay join preserving your privacy that's not obviously a pay join transaction. And BTC Pay Server does that now.

But if you use PDK, you just call that function and it'll be like, okay, either use a fallback transaction or construct a good, safe, secure, privacy preserving pay join. So how does it determine if it's good, safe and secure? So like if one of the inputs is obvious, I don't have the, there's a paper that came out last year that went into really great detail to identify these that we didn't know

were identifiable. But I think it's like if there's a really big input and one of the outputs is also very large and the payment amount is trivial in comparison to that, then you can find out what the payment amount is. But if the inputs are relatively similarly sized and the payment is significant compared to those inputs, then it's more difficult to parse which one is the input and which one is the change. Or it's like less likely that if you make an assumption that the big input is also the

big outputs owned by the big output, then because you don't, because it makes it more difficult to make that assumption or it's less likely that that assumption is true you have you're said to preserve privacy so it's basically calculating something in the background that compares the payment that they're looking to receive with the utxo that the sender's putting up and then going using coin selection to find the utxo that sort of make it very hard to figure out what the actual payment was. Yeah, you choose an input so that

one of these varieties of unnecessary input heuristic is not created. That's the idea. It's like a subset sum problem, so you have to make sure, because you can use more than one input, so it's like the subset of sender inputs and the subset of receiver inputs won't be associated together and neither will the payment amount. Yeah, it's fascinating.

So what is the current state of PDK? Like obviously you just released the announcement blog post earlier this week. Obviously you've been thinking about this for a while and it's probably important to touch on something you mentioned in the blog post, which is you decide to make PDK separate from something like BDK for specific reasons.

You did this intentionally. Why have a separate development kit and not just try to get this implemented into something like BDK? Because it's a different thing, really. So PDK right now is, I'd say, The sender is a late beta, so the sender works. It's been in the wild. It's been in Bitmask.

It's been in PageJoin CLI. It's been in NoLooking for quite some time, which are just different PageJoin apps. And the receiver is early beta, so the receiver works, but we need more extensive user testing before we can call it a version one and have the interface be concrete, say that we're pretty sure that the interface won't change.

So that's the status of PDK. I really started working on PayJoin and Rust to have this idea of a kit where you could put it anywhere. So instead of having an application code where you need to use Wasabi, you need to use Samurai, you need to use JoinMarket, this can be dropping anywhere. And I was really lucky to get to work with Evan Lin, who works on PDK very closely.

when this was early, before he was granted by Spiral. So we were working on these lightning pay joins. And because he knew that so well, he understood that BDK is really a wallet software. Underneath that is this thing called Rust Bitcoin, which has been around for years and years. LDK uses it and BDK use it, but that's all the primitives. That's all the consensus details, the consensus data structures,

where BDK manages the keys. BDK makes sure you're not spending the same UTXO multiple times without knowing it. It's doing some coin selection for you, and it manages output descriptors, whereas PayJoin is doing that PSBT negotiation and the networking. So right now, Will Owens is an awesome Summer of Bitcoin intern. and he's being helped out by Steve Myers of BDK to get those together.

One of the first integrations was with that Bitmask app. That's beta.bitmask.com. It's a great web wallet that uses Lightning and Bitcoin using LDK and BDK, and they even have RGB assets. So we proved that it could be used with BDK, and we're working on finding what's common between different BDK pay join combinations. So eventually, I think it will be possible to have PayJoin as a feature flag in BDK. But there's always a little bit more work that needs to be done to include PayJoin in your app.

And for that reason, I think it makes sense to have the focus be on the pure protocol, PSPT protocol. So that's really well tested. That's well understood. A lot of eyes are on that for that reason. And we can support that within BDK from that perspective. yeah that makes a lot of sense and so senders been in beta for a while receivers just getting beta like what else like what would make you happy in terms of the state of pdk like in a in a form where you'd be proud

to send it out into the wild and have the people begin implementing it into their their software Hmm. I'm proud of PDK already. I think the Rust implementation is suitable for people to implement and integrate, and people are doing it. We're certainly growing, and after putting the blog post out and getting support from the community, there have been a lot of interest. The reason my voice goes up at the end and I'm a little... i know it's not complete is because it's still rust it's not possible to use in any language you want or it's not easy so we've got to work on bindings and the cool thing about borrowing the architecture from ldk and bdk is that there's a bunch of people already working on

a sort of canon way to think about bindings so no matter what project you're using you can be familiar with it and we have some basic matias from trident has been working on python bindings thunder biscuit has been a great help to unify the bindings between multiple languages and michael from bolts has been really helpful in helping set up a roadmap for what wasm bindings could look like for typescript and javascript and once we have solid bindings it's really possible to rely on all of the review and security that's gone into the sender and receiver. So knowing your implementation is spec'd right,

knowing that coin selection algorithm is going to avoid the heuristics that are going to identify you as pay joins and still be able to directly plug in using whatever language you want. Yeah, that seems pretty massive. And Thunderbiscuit just got a grant from Spiral or the HRF, correct,

to focus on this full-time? congrats to thunder biscuit yeah he's been amazing there's this thing called uni ffi from mozilla that they use to write their uh password manager extensions once and then they use it in their browsers and they use it on all the different devices so we're using thunder biscuit has led us to use the same uni ffi bindings technique so we can write this library security focus library once and plug it in everywhere we don't have to worry about the security it's a really good model it's a secure model for this kind of software where people's sats are at stake yeah that's fascinating it's um always blows my mind talking to individuals like you working on this because

sometimes personally i get uh i came into bitcoin from like an economics perspective and got heavy into mining like five years ago so in recent years i've been really focused on mining and just like the economic side of bitcoins and its effects as a monetary good on the world and it's always fun coming back and having conversations with people like you actually working on the protocol that make all this work and make it work better for individuals at the end of the day um so thank you for doing that but i'd also like to like if you're successful pdk is successful when it is successful again confidently speaking here when it's successful and it starts getting wider adoption in wallets i know i've had this conversation in the past

and it's really hard to tell but like or foresee but like like how much adoption of pay join throughout the Bitcoin economy needs to happen before these common input ownership heuristics are completely borne. I just got asked this question this morning. It's really great to talk with you as well. I've been listening to the pod for a long time. You've had the pulse just on Bitcoin for so long.

So to get the questions that are at the most, they're at the core of the community, every facet of it, everyone's asking these questions. So to get them all at once lined up is a great help for the Bitcoin community at large to understand what the heck is going on. When I think about getting it out there to the world at large, I think about PayJoin's role in all of these technologies. So you have Lightning, which is really for payments. And I heard Matt yesterday say, oh, you know, if a store supports Lightning and PayJoin, of course, I'm just going to pay with Lightning. Obviously, it's cheaper, it's faster, it's well-established.

And, you know, PayJoin has a way to go until it's effectively breaking the surveillance. And to that, I say to think about PayJoin as more of a settlement layer technology. So Lightning always settles on the main chain. You always have to make a new output to have a new channel. And that's where pay join really comes in. It's about batching those settlements. Even when a receiver receives a very basic transaction, when they take that pay join, the best time to do that is when a fee market is low because they're doing a consolidation

so that in a high fee market environment, high block space market environment, they can make a transaction with just one input instead of two. So anytime you're doing settlement, having the option to pay join and having that option ideally decided for you by software that's making predictions will save money over the long haul. As far as when it becomes effective, it's effective immediately. So if you're making pay joins and some of your transactions are pay joins and someone watching you knows that then they're for all of those pay join transactions the common input ownership heuristic is wrong their assumption that they'd make is just wrong as it becomes more widespread than any transaction they look at could have that

likelihood to be a pay join so the example i gave in discord this morning was say you don't know any information about the people you're tracking but five percent of transactions you know break common input ownership heuristic let's say five percent of transactions are page ones there are other transactions or other reasons people make transactions that don't conform with that heuristic but let's say they're page ones then if someone were following your transaction in isolation they would say okay i have a 95 probability that these inputs are both owned by the same person. And then if they have another transaction, they have that probability again. So as these are chained together, they're all independent variables, then the probability

that they can follow some input to its output goes down substantially. If you have one 95% chance probability times another 95% chance probability, it just gets weaker and weaker as time goes on so you don't need that much to make tracking bitcoin over a few different transactions very unreliable yeah that makes sense then so at that point like a chain surveillance company wouldn't have confidence in your and whether or not you control certain UTX codes, they may still have confidence about other individuals

not engaged in payjoin transactions outside of that. But there's a point, sorry, there's a plane flying above me now. This is the back porch studios, always fun. But is there a point where, actually, I don't know. My assumption is it's isolated to people in PageWing transactions, the privacy that's provided them. Is there any critical tipping point where, say, like 50% of the network is engaged in PageWing transactions, the other 50% is afforded benefits of that individual privacy people transacting in the PageWing fashion are getting? this is a question I really wish I had a better grasp of because I'm not,

because of course the surveillance companies act like they know exactly what's going on. That's how they make money. They tell people, Oh, we know we can track with certainty, but I don't know where the hammer falls on that, where I think we'll find out in this bit fog case, how reliable the public thinks this tech is. but if someone analyzing your history knows you use pay join or knows that the wallet you use supports it then they can really no longer make that assumption so you get that safety just by

having your wallet support it even if you're not using it especially because it's something that is automatic in terms of user experience is not something you have to opt into really and manually do as a sender and even as a receiver with serverless pay join so if wallets support it you have that assumption across the board and then even if someone can't identify what wallet you're using say you're just using something that supports newer technology like segwit or taproot then there probably is a chance, at least after an exchange pays you, that you could be using a wallet supporting pay join. And these common input heuristics used to track you aren't really valuable anymore.

Yeah, the Bitfog case will be very interesting. What worries me about that case is it's becoming pretty clear that it seems like chain analysis is they're basically over advertising their abilities but you can see a case where god damn it a helicopter coming right over me give me a second technology i'm really curious what a jury will be convinced of is in that case because that's what it's going to come down to is how the experts that uh you know everyone looks to to trust can convince a jury and i think it's it's pretty obvious that their techniques aren't perfect that there is a chance that every step along the way even without pay join has a high degree of ambiguity and could

not be what they're saying it is but yeah we'll see yeah well that's like the conversation i've been having in my mind too because you can see a case where the jury has no idea what's going on they could convict um this gentleman i forget his name off the top of my head uh with bad information and then chain analysis can continue to use those bad techniques to just essentially buddy up with the government to throw people they don't like in jail but at the end of the day on chain like really like the truth is they don't actually know what's going on it's like what like is that a silver lining to all this like it's weird that chain analysis and the government can go bully people and throw them in jail with bad information but we also have the knowledge that the truth of

the situation is that they actually can't identify people on the chain i don't know if i'm articulating this correctly but you see yeah i mean they definitely can throw people in jail unfortunately before a trial this dude is in jail he is suffering um but i have a lot of i do have faith in the American justice system, I like to think I do, that even if it got through one jury trial, at some point, there's appeals, there's an appeals process. And it's quite plain that what they're doing is heuristic analysis, they're making assumptions to come to a conclusion about what someone did or did not do. And this is, I mean, all law enforcement is heuristic analysis. Um, if you're dressed up wearing a nice shirt, if you have a

particular ethnic background, it tends to be the outcome of a traffic stop might be different for you than someone else. But that doesn't necessarily mean the justice system when all is said and done will not be able to see through that. Yeah. Yeah. It's fascinating times. So you seem pretty passionate about this right to privacy, particularly as you transact with Bitcoin. Do you see a potential timeline where Bitcoin, maybe it doesn't fail, but isn't as successful as it potentially could be due to a lack of privacy assurances for individuals? Hmm. the biggest issue with privacy in financial markets to me is that the people that

censor that make the decisions of what's okay and what's not are not necessarily elected they're not chosen through a democratic process and they can be there for a long time so i think markets would be better off for people to not have the opportunity to bully others and make rules without being elected and being held accountable and bitcoin gives me a lot of hope that that's possible uh the fact that this privacy issue was left in the white paper is exciting to me because it's like oh nice satoshi gave us some directions into what's possible what we can fix um it gives me something to do

so there's one line there's like i think there's one section about privacy in the white paper which talks about common input ownership heuristics satoshi says if some inputs are spent in a transaction then they can be assumed to come from the same person even though addresses are pseudonymous and you can get a degree of anonymity by receiving payments using a fresh address so because we can pay join because we can make these transactions using interaction that break that heuristic we can bust that last open privacy problem like it's a long path ahead and it will be iterative but i i have faith that it's possible to solve the problem and it's not so much that i think bitcoin would fail because it didn't have privacy to me it's more

it's more a matter of when it happens that is the thing that's holding adoption back like the reason people like gold and hold it in their treasuries is because they have the rock they know they have the rock they know no one saw them receive the rock and i think that's possible for bitcoin and that's going to make it grow when it's possible and people are going to have a lot more eyes and trust in the system when they know it has that because when people say oh bitcoin's private it i think a lot of people know that's bs it's just not they they get intuitively that that can't be the case but if you can prove that's the case people will be a lot more comfortable to use bitcoin and allow it to be far more widespread agreed that's why i'm really excited

about what you're working on too because there's a lot of um a lot of people who believe that Bitcoin can never attain a sufficient level of privacy assurances without upgrading with something like confidential transactions or zero knowledge proofs. Like we need a massive protocol upgrade to get the privacy that people really want at the end of the day. And I never believed that to be true due to the fact that CoinJoin exists and things like PayJoin exists. It's just more effort that's needed on the software side of things to make the user experience such that people are using Bitcoin and coin selection and PSPTs with multiple inputs smartly. I see no reason you couldn't coordinate a pay join that involved more than two individuals. I think you get the CoinJoin process where multiple people contribute and where you have ambiguity from payments in the user experience of scan a QR or share your address URI with someone to signal your intent. And then the result of that is a transaction that, like PayJoin, doesn't stick out as something weird.

It just looks like a batch and gives you the unlinkability from your inputs and outputs to the point where even the person you're paying doesn't know what input you paid with, which they do in PageJoin version one. Yeah, so let's flesh that out. How would like a multi-receiver PageJoin work? When the time comes, I'll release some in-depth documents. but I think it could work with a coordinator. You could use an e-cache system. This is what like Max Hillebrand has suggested on the mailing list in the past

where you register inputs and outputs and then somehow you split those outputs based on the other inputs and outputs. So there's a degree of ambiguity. How that all comes together, how it fits within the QR code paradigm is yet to be seen, but I'm convinced it's possible. Why are you convinced it's possible?

Because all the basic tech is there. You really just need a way to coordinate. It's a matter of sending enough messages and blinding the sensitive information, and we know how to do both of those things. Yeah. So just more time needs to be spent on this problem to actually figure out how to...

Yeah, you need engineering resources. You need smart minds. You need people who collaborate and you need people who don't give up on the problem. Yeah, that actually brings up a good point. It's something I've had discussions with some core devs over the last year, particularly like this concept of like burnout,

particularly within Bitcoin core. What are your thoughts on the state of just developing on Bitcoin right now? It seems like there is a fair amount of burnout, and with CORE specifically, it's really hard to get stuff done. It tends to frustrate people. I think it's actually getting better than it has been. I think we had a low point between the bear market and legal trolls, but we're seeing more and more support in the world of grants. I think we're seeing people be quite generous and realize the need.

And I think because it's financial technology, the companies that rely on it are more likely to support it than they are plain data or networking open source stuff. Because their money is secured on it, they can say, okay, we can spend this percent of our budget to make sure it's secure by supporting the people whose responsibility it is to secure this thing. So I'm optimistic in that regard. um i know a lot of people it's really difficult it's been difficult for me to get grants of course i'm not like super well funded i've sacrificed a lot to be able to work on bitcoin and persevere through tough times with it um it's not easy to maintain this kind of development when you're not you know venture-backed or working for a megacorp who's paying your salary and those opportunities are super appealing, especially before the past year to go and work at Facebook

the year you graduate and make, you know, 300 grand a year just a couple years later is super appealing. I understand why people want to do it. And the other thing about the grant programs that I would like to call for change for is I think a lot of these programs focus very solely on non-profit which is different from sin coin land i think a lot of the grants are conditional on okay you're not going to make any money doing this and that that makes projects that are unsustainable like even if you had a non-profit it it's not necessarily a bad thing that that makes money to sustain the project in fact i think that's what you want to encourage i think you want to encourage business models that work that way those business models can

support more and more development and you get a spiral upward. So I hope that can change. I hope some of these grant giving organizations can say, okay, just because there's a business model associated with this does not mean it's ineligible for funding. And in fact, that could solve the problem that we keep running into where our grant money runs out at the end of a year because this person's work is expensive and is not sustainable without a continuous donations what are some examples of like projects that could make money that aren't getting one really good one that succeeded is the bolts exchange atomic swaps that's been like a huge success story i think is that got i guess that got some support from human rights foundation it's not like huge support

of course but they're able to turn that into a real business that at least can sustain i don't want to get into you know stuff that uh hasn't been funded because i don't want to complain i think by and large all of the granting has been overwhelmingly positive directed in precisely the right direction. I don't think much of it has been misguided at all. I think the people giving these grants are making very good decisions and supporting the developers that need it.

I just ask that they, you know, consider to open their mind a little more. Yeah, I think that's a fair ask. It makes a lot of sense. And technology is important. Like you mentioned it, like it's been hard for you, but what keeps you going? thank it's meaningful man it's i feel like i'm doing something that

can help people and i see a light at the end of the tunnel we're working on bitcoin like i'm not working on some esoteric uh zoology that really requires this constant funding to sustain we're working on bitcoin this is we're working on financial markets having expanding knowledge into this realm is worth something tangible so i can keep going it's not a problem yeah well again thank you for doing the work you're doing i think it's extremely important um and i'm very it's fun everyone in this has very high uh well not literally everyone but i think on average the people that i work with in bitcoin have a high degree of humility and collaboration uh being able to work on network protocols in particular where so much of the culture

is inspired by this idea of rough consensus and decentralization is really easy to fall in love with it's just fun yeah yeah and you mentioned you see the light at the end of the tunnel so i'm not going to put words in your mouth but um stoked a question in my mind is like Like, do you obviously there's always going to be need there's always going to be the need to do maintenance on the protocol. But are there like a few things that are in the docket that may or may not get merged into Bitcoin or added to the areas above the protocol layer that if added, emerged would get bitcoin to a state that you think is okay to run sort of at that state into perpetuity i'm not sure i know exactly what you mean like i see some sort of change that's coming that's going to make bitcoin private or are you talking about something else

like just in general like if we got like some people think like we get l2 um uh and a couple other upgrades like bitcoin at the protocol level at least we'll be at a place where it's like all right this is good enough like if we had ossification like this would be okay um is there a combination of things like that in your mind that at the protocol were to get to you'd be like all right this is pretty robust pretty resilient i don't know I focus very narrowly on the privacy problem sometimes where I feel like I'm missing things that are happening on the mailing list or at the protocol level it seems like there's a lot in terms of p2p privacy that's happening that I'm really excited for and probably my optimism

comes from support like this of PDK and the idea that pay join can make a real difference. And some of the research I've done that convinces me that we can get reliable privacy in Bitcoin at a systems level instead of just with specific applications. Like that mindset, I think is really what changed it more than anything. Because when we were all focused on use this application get privacy i just never saw how that could expand to all of bitcoin but thinking of protocols like lightning and pay join as kind of like in the operating system model when you're doing systems programming you think of the operating system and then you have drivers on top of that to use your peripherals which are kind of you know to run your audio and

whatnot and i think of lightning and pay join and other systems like device drivers you're not using a device necessarily but it gives you a feature and because they're engineered to be systems that run in all these different wallet softwares they become become ubiquitous i think we're getting to a point with privacy where i see that as becoming possible and that's where my optimism comes from is like this system's perspective rather than the application's perspective oh yeah yeah that makes a lot of sense and for anybody listening right now that wants to help push pdk forward maybe contribute where should we send them page on dev kit.com sorry page on dev kit.org is the place to go first yeah i know i don't even

know my own url um so the github and the discord are linked there we're on twitter too as payjoin devkit.org if you want to just an overview of payjoin payjoin.org is that uh we're quite consistent in discord there's a bunch of different projects you can get involved in so there are a couple designers shout out to bob space for supporting this work and willing being willing to collaborate and bdk of course is steve myers and summer of bitcoin are doing a huge help to get pdk out there and then if you want it in your specific application the bindings are growing and if we can work with you to get a implementation into your wallet there's a number of people who are willing to get that done what are uh the top wallets on your list to get it implemented

then um i mean whatever bull bitcoin's developing that is on the way we've got some drafts for that and i think getting in an exchange is going to really change the game bolts is another kind of receiver exchange that could be super functional and helpful the bdk cli of course um i think yeah i don't know who wants to step up to add serverless pay join first there are a few people of course like the people i mentioned that are willing but as far as large-scale rollouts it's hard to say who's going to be first even voltage has because of the lightning pay join they've reached out and talked about okay if we can introduce this in the dashboard and you can just fund with a page join that's so much easier than you know opening all these channels separately

they could just open the inbound channel and the batched outbound channels you wanted in one funding transaction so yeah i just get uh i get kind of overwhelmed with all the different places this could go yeah what could go wrong with the serverless implementation the serverless implementation i think the biggest risk is that we build something with either too many dependencies or that's in too inflexible so people don't want to integrate it and i think this is what's happened with some of the ones i mentioned previously like where you have a spec and it works and it's great and people that use it love it but it only works with one application so getting that early feedback which i've gotten a lot of fortunately

i've gotten a lot of collaboration people want this is critical to having a successful rollout and i think that's what the bit process is for uh it gives you a clear way to post on the mailing list first get people like marty to scratch their head and say what's turn and want to talk about it and then get other developers to come in and say that's wrong don't do that this might be a better idea and come to that rough consensus where you can address everyone's concerns build implementations test it out and have something that's robust and future proof yeah that makes a lot of sense well keep crushing it dude this is awesome very uh very excited and feel fortunate that an individual like yourself has dedicated their life to solving

this problem because like i said earlier i think it's a a big problem to solve and would do the world a lot of good if it is solved so thank you thank you it's happening we're winning we are winning we're not going to win we're winning we just got to keep winning it's the always have been we always have been winning it just doesn't always seem like it that's the truth so dan thank you we will um hopefully we can do this again there's more more to talk about when this is widely adopted throughout the space i'd love to do like a group discussion with you and francis um because i love francis number one and number two i think underrated in terms of like how he's thought about the infrastructure of his exchange and

all the stuff that he's built and open sourced for others to leverage and i think like you said bull bitcoin getting in this and like adding it to their stack their open source stack could be massive for people i think other exchanges could see what's possible when someone takes a chance and francis has been on the pay join bug for a long time i think the tech is just catching up But all the potentials you mentioned, yeah, I'm interested. It sounds awesome. Let's do it. Yeah.

All right. Well, you go. Enjoy your 4th of July weekend. I'm going to go do the same. And I guess I'll see you on the internet. Thanks, Marty. See you on the internet. All right.

See you, Dan. Peace and love, freaks. Take care.