Citadel Dispatch

Share on social media:

Dan is the maintainer of Payjoin Dev Kit. Payjoins are a type of collaborative bitcoin transaction that can reduce fees and improve privacy. We discuss the potential for broad industry adoption among bitcoin wallets and companies.

Dan on Nostr: https://primal.net/p/nprofile1qqszvkpk9scn064gq8awgp97xmlusrsk5cwy82y35wsyd0kykuhynzspqmlwl
Dan's Website: https://bitgould.com/  
Payjoin Dev Kit: https://payjoindevkit.org/   

EPISODE: 154
BLOCK: 891950
PRICE: 1210 sats per dollar

Video: https://primal.net/e/nevent1qqsyzvxeztjtjkur9y6t2a34768545vpw6e83e4wnwg6u29uecmv42qg3pvdr

support dispatch: https://citadeldispatch.com/donate
nostr live chat: https://citadeldispatch.com/stream
odell nostr account: https://primal.net/odell
dispatch nostr account: https://primal.net/citadel
youtube: https://www.youtube.com/@CitadelDispatch
podcast: https://serve.podhome.fm/CitadelDispatch
stream sats to the show: https://www.fountain.fm/
rock the badge: https://citadeldispatch.com/shop
join the chat: https://citadeldispatch.com/chat
learn more about me: https://odell.xyz

(00:06:23) Bitcoin and Freedom Tech Discussion

(00:08:02) Payjoin and Privacy Enhancements

(00:18:22) Payjoin Dev Kit and Integration Challenges

(00:30:10) Technical Aspects of Payjoin

(00:47:00) Future of Payjoin and Multi-Party Transactions

(01:00:03) Open Source Funding and Community Involvement

[00:00:00] Unknown:

Where's the upside for crypto?   This is Sectors Up Close, and we're talking cryptocurrency.   Bitcoin hit a $20.25   low on Monday,   sliding alongside equities   even though president Trump had promised favorable policies   that would make The US the crypto capital of the planet.   So what's happened to the optimism around cryptocurrency?   Well, Andrew O'Neil is digital assets managing director   at S and P   Global Ratings. Andrew, cryptocurrency was intended as a departure from the traditional financial system, but isn't it moving a lot like any other risky asset at the moment?  

[00:00:38] Unknown:

Well, Elena, thank you for having me. I think, you're referring to price movements in the last few, few days, few weeks. Certainly, we've seen,   a trend where,   markets have moved to a risk off,   paradigm, in recent days. And, and, clearly,   crypto has joined other asset class in that movement. I think when we come back to why   crypto could be,   an asset that behaves differently, a lot of the assumptions behind that are things that, you know, are are still developing,   may over a number of years become true.   But I would also highlight that then among   crypto assets themselves that there are significant differences. And when we're talking about that   asset that may behave differently, that may be a,   a hedge against current TV basement, for example, that may be uncorrelated   to, to stocks. We're primarily focused on Bitcoin. We're focused on its characteristics as an alternate form of money. We're focused on the fact that it's decentralized, that it's geopolitically neutral,   And we're starting to see adoption in that sense, so that narrative of investment appearing among institutional investors, among public sector investors, among national governments.  

But that but we are still very early in that trend. And so it's not very surprising that in an environment where investors are rapidly  

[00:02:03] Unknown:

switching risk off in their portfolios, that we're seeing some, some correlation between crypto assets and other asset classes. Yes. Last year, of course, there was a lot of talk about Bitcoin being the new gold, about it becoming a safe haven asset. When do you think we will see that happen then? Or perhaps what do we need what needs to happen first? We've already seen,  

[00:02:22] Unknown:

a an executive order announcing the creation of a,   US   strategic   Bitcoin reserve.   And,   what that has done so far is allocating   existing holdings of Bitcoin,   that, that the, the government has acquired through various   law enforcement procedures,   to this reserve that will not be sold.   There is there there was some discussion in that executive order about adding to that reserve over time if a way to do that can be found that does not bring additional cost to taxpayers.   So we will see over the next couple of months if proposals emerge   or or brought forward that that that are that,   that carry that effect. There was a proposal made last year by senator Cynthia Lummis,   which aimed to accumulate   a million Bitcoin over a period   of five years, which would clearly be significant,   well, bring significant buying pressure to, to to Bitcoin markets. That would be, for context, more Bitcoin than is actually produced   on an annual basis coming as a as a net new,   demand, for the asset.  

So   there it's possible that some of the,   early exuberance this year, in Bitcoin price was   something like that being announced. So far, we've only had the announcement regarding Bitcoin already held, but we'll see in the in the next few months if something further comes on that. Bitcoin investors have been a bit disappointed so far with the second Trump administration.  

[00:03:50] Unknown:

Were they expecting further crypto friendly moves that we haven't seen yet? I think there is that aspect around,  

[00:03:56] Unknown:

additional buying coming from from the National Reserve.   Beyond that, you know, I I think   crypto markets do bring in a certain amount of leverage that can lead to,   liquidations   and more rapid price decreases.   So we've kind of experienced that in the last few days with   increasing liquidations across centralized and and decentralized exchanges and crypto.   But,   when we look at some of the early developments that we've seen in,   since the change of administration, we've seen the repeal   of SAB one twenty one, which was   a a a a regulatory measure that effectively   made it impossible   for regulated banks to provide custody services on crypto assets. And so that's a major change in terms of bringing institutional   players into the market.  

We expect to see regulation emerge on stablecoins   in The US market this year, which will bring,   more comfort   to regulated institutions using blockchain technology and using crypto rails   to transact on, and, again, more emphasis on participation in in, in crypto markets. The last piece of that puzzle is market structure, which is   a legal framework looking to say which regulator will be responsible for which area of the crypto market.   That, that that   that's also,   on on, on the to do list of the US legislature, but, these things take time. And it's certainly not surprising   that,   that, that those things have not yet been,  

[00:05:28] Unknown:

brought into effect, but we would expect to see movement on that, this year. That was Andrew O'Neil of S and P Global Ratings. Don't forget, you can watch more videos on Reuters.com.  

[00:06:24] ODELL:

Happy Bitcoin Friday, freaks. It's your host, Odell, here for another Citadel Dispatch, the interactive   live show focused on actual Bitcoin and Freedom Tech discussion.   That intro clip   was from Reuters   interviewing some suit from S and P,   talking about Bitcoin.   Completely irrelevant really to our today's discussion, but it it felt,   notable enough to to put in the beginning of dispatch.   So I wanna thank you guys for sitting through that with us.   As always, dispatch is a % audience funded. We do not have ads or sponsors.   It is supported by   all you ride or die freaks that continue to donate sets to the show. I see we have   some of our rider dies already in the Nasr live chat. It's good to have the Nasr live chat   back up and on screen   today for this episode   or this show.  

I will start off by saying   that I may have blamed some technical difficulties on ZapStream   by Kieran,   but it appears my stream key was rotated,   and I had not adjusted that on my side. So   hand up,   I'll take full blame for that. But we have Super Fat Hour has already zapped 21,000.   EZ has zapped 3,000.   And our top boost from the last   two shows was from Wood Butcher. Wood Butcher,   4,200 sets, and he said, God bless capitalism.   Love to see it.   We have ride or die freak Dan Gould here to join us. It is the second time on the show. First time as a solo guest, we'll be talking about PayJoint. We'll be talking about   using Bitcoin privately. We'll be talking about many things. How's it going, Dan?  



[00:08:14] Dan Gould:

Good. Talk about whatever you want.   It's,   something I've been looking forward to to a long time.   Yeah.  

[00:08:22] ODELL:

I I an interesting place to start, just a relevant,   newsworthy item.   I was pretty excited about this DOJ memo that came out,   saying that they're getting rid of their crypto enforcement   division   and that they will not be   focused   on individuals and developers that are running   or that are maintaining   sovereignty focused Bitcoin software. I think they called out by name,   mixers and tumblers   and self custody wallets. Do you have any opinions on that?  

[00:09:00] Dan Gould:

As soon as that came out, my first reaction was, I can't wait for Lola leads to report on this, which did come right after, from the rage.   It's an internal memo. It's not really   a law. It's not even guidance like   FinCEN has. We'll see what actually changes.   It's a narrative shift, but   I'm cautiously   optimistic   to look at it, as anything more than that.  

[00:09:28] ODELL:

Yeah. I mean, I I appreciate the constant skepticism from Lola.   She is quite unique in the Bitcoin journalism space. And I I don't think she's wrong. Right? Like, it's definitely not   a panacea, but,   I think it's also absolutely massive. Like, I think it's pretty crazy that a year ago,   less than a year ago, we had the samurai developer start in jail.   And today, we have   the DOJ shuttering the same crypto enforcement division that led that case.   I mean, they're obviously still in jail. They still have a court case.   Lola   rightfully pointed out that   they, said that that part is out of scope. They, like,   took that out of the memo.  

But, yeah, I think it's a big deal. I think she also reported today,   at least on Noster,   that the broker dealer rule from the IRS is out, which wanted to do KYC on self custody exchanges.   And she seemed pretty optimistic on that. So I don't know. It feels like a lot of progress is being made. It feels like   we have a window here,   where at least the US government isn't actively trying to throw open source contributors into the gulags,   and we should probably be seizing the moment.  

[00:10:50] Dan Gould:

Absolutely. It's time   to take   as much as we can   that enables self custody, like sovereign self custody mainstream,   and   raise the bar in terms of what's expected   for bare minimum privacy.  

[00:11:08] ODELL:

Damn right. Okay. So let's talk about let's just start let's just dive right in. You've been focused on PageJoin,   specifically PageJoin DevKit.   Let's start high level. What is PageJoin?  

[00:11:21] Dan Gould:

Pay join is the most fundamental way to batch   transactions   on the input side.   So   almost everyone's familiar with output batching. When you make a withdrawal from   any exchange. They're gonna   make a ton of inputs in or a ton of outputs in that transaction to pay out their users because they make less change and they share the overhead and they save money.  

[00:11:46] ODELL:

But So, like, if if I do, like, a strike withdrawal,   you'll like, when you look up your strike withdrawal on mempool.space   or whatever,   that transaction is really sending Bitcoin to maybe 200 people, 300 people, including you, and that's that output side batching. Exactly. Because they save a ton of money, and  

[00:12:06] Dan Gould:

it doesn't clog   up mempool so they're able to have high throughput so that happened all in 2017   when mempools were full and full and full and fees were getting more and more expensive   Everyone's like, how do you scale a database, which fundamentally Bitcoin blockchain is, and you do that with batching. And that   is consensus. I mean, there was even   calls from   the community at large, like naming and shaming people that didn't do batching until they did it. It was very effective.  

[00:12:38] ODELL:

Okay. So but in that situation,   usually, it's just one or two on the input side. There's, like, one or two input transactions.  

[00:12:47] Dan Gould:

Well, yeah, there there may be any number of inputs, but they all come from the exchange. The exchange   constructs this transaction so that there are enough inputs to fund all of their withdrawals.   They sign it, and they post it to the network.   And that has been great for   throughput.   It's reduced the fees everyone pays,   but it doesn't address this   problem that even Satoshi left in the white paper that anyone looking at a transaction can assume that all the inputs came from the same person.   But because of the way that   Bitcoin works,   any inputs can be spent in a transaction as long as they have a signature.  

So if   the person sending the transaction and the person receiving the transaction   both talk to each other, they can contribute inputs and break that assumption   and   that lets us do a ton of stuff. It lets us   save fees because it's even better batching. You're packing more intents into one transaction   and it raises the bar in terms of the minimum privacy everyone gets because that assumption   about   how money flows in the chain   is no longer true. That assumption that all the inputs come from one person.  

[00:14:08] ODELL:

Right. So   just to unpack a little bit, with Bitcoin surveillance,   and transaction tracking, it's all just probability analysis.   And   so the what is that probability analysis to property   probability analysis is trying is is these surveillance firms are trying to figure out   what percent chance is there that ownership has changed hands between Bitcoin UTXOs.   And the main the main heuristic they use for that   is common input ownership heuristic. This idea that everything on the input side is owned by the sender and who's a single person or a single entity.   With pay join,   multiple parties can contribute inputs.  

So all of a sudden, you break that fundamental   probability assumption that everyone   on the input side is the   same the same entity.  

[00:15:09] Dan Gould:

Yeah. And there's other tech that Yeah. Breaks this too, but pay join is kind of   pay join is the most   convenient way to do that. Everything around   PayJoin   is set up so that   any two software services can set up a standard way that they can talk to each other and arrange   to make this kind of batch   if they're both online.  

[00:15:35] ODELL:

So then   why don't you so so   the   the the privacy improvement is clear. I mean, is that you're breaking this you're you're breaking that probability assumption, your that common input ownership heuristic.   How does how does that process of   of adding additional inputs that aren't, you know, maybe they're not even necessary to,   fulfilling the transaction. I mean, you could do the transaction without PayJoin. How does that save fees?  

[00:16:08] Dan Gould:

Yeah. The really interesting   savings comes from   creating   fewer coins overall. So this is the same thing   with   receiver side batching that I think   people,   it doesn't readily, it's not readily apparent to people the first time they think about it. So when you batch a bunch of outputs,   yes, all of these transaction intents share one transaction and they share that 10 byte overhead.   But really the big savings comes from not every single   output   to, someone withdrawing from an exchange, say, creating change.   So if there's a change for every single person that withdraws, that input then needs to be spent at some point in the future.   But if you batch them all together,   you can batch 300 people and just get one change. And the input is actually the expensive part of a transaction that includes   the the witness and the script.  

So   when you do a pay join, you can do the same sort of thing where if I was gonna send   some exchange   some money and they knew they needed to make a withdrawal, they would have to take my UTXO   and then they would need to spend it again   and we would both create   change. But instead, we can do something called cut through   where some proposal   to a receiver, an exchange from a depositor,   can directly fund withdrawals. So So in some cases, the exchange may not even need to spend their internal coin.   The sender   can fund the transaction   that directly   pays   the,   the people making withdrawals.  

And, overall,   there are both fewer transactions and there are fewer coins created. So that   that is where the savings come from.  

[00:18:00] ODELL:

So if there's, like, a hundred people depositing to strike at the same time as   there's 50 people withdrawing from strike,   then those hundred people that are depositing could actually be on the input side of the withdrawal transaction,   and you kinda knock you knock off both sides at the same time.  

[00:18:18] Dan Gould:

That's what we wanna do long term. Yeah.  

[00:18:22] ODELL:

Okay. So what is page join dev kit, and where does it   fit into this whole   mission?  

[00:18:31] Dan Gould:

Yeah. Page join dev kit.   Pedro and DevKit was the way to get me to,   have people understand what the hell I was working on because   Lightning DevKit was working so well, Bitcoin DevKit was working so well, and I was working on kind of the same thing,   a software development kit   to   let any wallet or service   take advantage of this technology.   But without that   branding,   people didn't people didn't get what it was. And this is where,   PayJoin's a bit different than a lot of what has come before in terms of privacy tech.   It only really works if everyone is using it or if a significant number of people are using it. So PayJoin DevKit lets you take this off the shelf   protocol implementation   and plug it into your wallet. So Bold Bitcoin   just released   in December   this   PayJoin DevKit integration into their wallet,   and we were able to demonstrate its use also in Bolt's   Exchange and Liana over this past week. So it's an off the shelf toolkit.  

Any software can take, plug into their wallet, and activate PayJoin.  

[00:19:42] ODELL:

Because if   for this to work,   you need you kinda need widespread   wallet and, like, service ex support. Right? Like, the exchanges would need to support it and the the people who are,   I guess, the people that are depositing   their wallets would need to support it, not necessarily on the receiver side. Right?  

[00:20:05] Dan Gould:

Matt, in an ideal world, you'd want the receivers to do this too. Oh, I guess so. Any any transaction intent, you can think of this as kind of a pseudo mempool. It's like before   we get to mempool, if we're willing to communicate with other people, we can take all the transactions we wanna make and batch them together.   And everyone Right. Saves money. But, yeah, that's the idea.  

[00:20:25] ODELL:

You need as many but you just need as many wallets and services to support it as possible for it to work at scale,   basically. And so dev the page join dev kit makes it easy for all of these different  

[00:20:36] Dan Gould:

maintainers to to add support. Right? Yeah. I think of it as HTTPS. That was controversial in its day, but now it's ubiquitous and so everyone has better privacy. The only real way we can do this,   upgrade   to Bitcoin   is by making it network wide, which in   the application world, if you're not changing the actual protocol,   you need many people to participate in. And   the   reason that PayJoin lets this happen across the network and not just between the people that use it is because a lot of the transactions   that went through this process look the same as transactions that didn't necessarily go through this process.   So you have   you have a greater degree   of   ambiguity   on whether all the inputs came from one person or not   for everyone.  



[00:21:33] ODELL:

There's a   if you,   so, like, if you just, like, see a non paid join transaction   on mempool.space, for instance, you you might not be able to tell if it's a paid join or not. Right? So it just breaks that. Yeah. It's it's complex because  

[00:21:48] Dan Gould:

there are a lot of other fingerprints,   but this is kind of the least we can do in a package that can be automatic for all this software. So you plug it into your wallet.   Your users don't have to take additional actions. It's just packed into the   flow that everyone's used to.   You send me   an address, basically a URI,   and, you know, like, some payment instructions, and I pay that   by pasting that address, and my wallet takes care of the rest. If there's an opportunity to batch, we do the page one batch. If not, we fall back,   and everyone gets this as a convenience. I think in the past, a lot of these techniques   have involved a lot of know how. And if you didn't use them right, you could make mistakes, and you might have paid a bunch of money and time and not even be any better off. This is about the widespread   increase for everyone. Everyone has   a higher   degree of privacy   whether they even use this or not   by existing.  



[00:22:49] ODELL:

And I love the it just falls back. It'll just do a regular transaction if the pay join   process fails. But the so, I mean, one of the the big not not necessarily issues, but trade offs with page join historically   has been that it needs to be   interactive and that, you know, so effectively,   senders, all senders and receivers need to be online to, like, coordinate with each other and sign and broadcast this transaction.   My understanding is that's no longer the case. And,   like, how are you handling that   information exchange?  

[00:23:27] Dan Gould:

The beauty of Bitcoin is that it's noninteractive. You just take a transaction you post it, you submit it to Right. Whatever,   mempool,   and eventually it'll get mined in a block.   Pay join takes advantage of the fact that most of us are online some of the time.   So   the fallback is there in case we're not.   But if we are, we can both   use   what's essentially a mailbox   to coordinate together. So the problem with   the past,   the his so there was there were two iterations. This has been going on since 2018.   And   the standard communication   required you to   run a public publicly accessible server to receive page lines. But we,   meaning the page join dev kit team,   came up with a   directory server   that hosts these mailboxes   and anyone can host one of these servers.  

And you put your message in the mailbox and the person that is   waiting for your payment is listening to updates for this.   And just like email, when that message comes in, they can reply to it. And if they don't reply to it in time, we fall back.  

[00:24:45] ODELL:

Okay. So it's still interactive. It's just Yeah. Like, it's a looser interaction.  

[00:24:51] Dan Gould:

It's asynchronous. So we don't need to be online at the same time because there's that box in the middle.   We   as long as we come on within some time frame, we're both comfortable with. And what is that time frame? It's like lightning is the same thing. Lightning, you need to come online to communicate and a big issue with like zaps is that it's a synchronous protocol for the most part right now. But if we   make that asynchronous, this problem goes away and that's where like   an npub. Cache makes things easier because they're always online on your behalf.   The   async pay join spec   says   there's someone that can always be online on your behalf. It's not exactly the same, but   yeah. What was the question you just asked?  

Like, in practice, how long do you think that period will be? Oh, by default, we set it to twenty four hours in clients just like,   you know, your typical lightning invoice, but it's configurable on the client. So application specific. I think exchanges with exchange rates will probably have   narrower constraints like b t c pays,   exchange rate holds for an hour.   And   it's   application specific. The point of the protocol is   not to   and I'm talking about the BIP 77 v two join async page on protocol that's   being finalized right now. Right. The point is that everyone can communicate on the same standard just to make a batch. It doesn't restrict itself   to the transaction needs to be of this certain shape   or amount or within a certain time frame is just a very fundamental, convenient way we can attempt to talk to each other,   and,   hopefully, we're able to. And if not, we fall back.  



[00:26:37] ODELL:

So,   yeah, I mean, I don't think, you know, even twenty four hours probably be fine for most people.   I mean, I there there's some there's some precedent already. Right? So, like, for instance,   at least   to my knowledge, both strike and cash app offer,   you can like pay for a priority withdrawal or you can get a free withdrawal that happens sometime within twenty four hours. Right. And plenty of people choose the I'm willing to wait up to twenty four hours. Usually it doesn't take a full twenty four hours, but I'm willing to wait up to twenty four hours to   have a free withdrawal.  



[00:27:15] Dan Gould:

And those are the best targets for the cut through because if if once people are queued up to have their withdrawal and a pay join comes into the exchange, that person depositing to the exchange can   preempt that queue. It can pay everyone.  

[00:27:28] ODELL:

Exactly.   So my point is is, like, there's already   effectively like real world user testing that people are like fine with that time period.   You know, maybe you'd want it to be a little bit shorter, but that makes sense to me now in practice,   like, just walk us through this.   If   let's free, let's use easy numbers. A hundred people are depositing a hundred people withdrawing   and it's a cut through pay join.   That means every single person   in that transaction   needs to be   online for at least a little bit during that period. Right?  

[00:28:06] Dan Gould:

Not exactly. So there's   there's a couple levels to this thing. The page r d two spec   is really only for   one sender and one receiver, but that one receiver can define as many outputs as they want. So your base case   is that there's a queue at an exchange   where people are willing to wait, a depositor sends some money to the exchange,   and that preempts the whole queue. If the   exchange needs to add some input to pay for that,   they   can add that input.   But   there's   because it's only one back and forth round of communication, it only really works with one   depositor.  

Now   we did just sneak in a feature   into   our   last release of PageOne DevKit that allows   multiple senders and senders to send to one receiver.   But still that one receiver is defining all of the outputs. So from the perspective of the depositor, they're only interacting with the exchange,   but the exchange is free to choose all of the outputs. So they can forward payment to anyone, but those   people making withdrawals   are not part of the interaction.   It's just the deposit side is. Just the deposit side because they need to provide signatures. And because they need to provide signatures, you need to   interact until that's done.  



[00:29:30] ODELL:

Right. On the on the withdrawal side, it's just the exchange providing, like, all the withdrawal addresses like they usually do. Yeah. And then have the amounts or whatever.   Okay. So that's way more doable too because then the exchange just has, like I I guess you use the word queue. It has, like, a queue of withdrawals that are, like, their free batch withdrawals, and they just wait till   they have   an appropriate amount of inputs on the the sender side to do the transaction.   Boom. Done.  

[00:29:59] Dan Gould:

At some point in the future, maybe we can have receivers too, and we can have the receiver specify what output they want   because then then even the   exchange wouldn't know exactly what address they sent to. They'd they'd get a proof of payment, but, like, for the highest,   version of this, I wanna be able to send to you. I don't really care what address you have. As long as I get some proof that it ended up in your address, I don't actually wanna know what your address is.  

[00:30:26] ODELL:

Right.   That'll make sense to me.   The you mentioned earlier   that there's some nuances   in terms of PayJoin fingerprinting.   I mean, the Wallet fingerprinting. Yes. Yeah. The hype the hype   answer is always, you know, with pay join, if we get like 5% of transactions using pay join, then everyone has privacy.   What are the new, like, where, where are the nuances there in terms of,   being able to tell which transactions are paid join versus which ones aren't?  

[00:31:05] Dan Gould:

It's tough   because this 5% number just comes from what people think of as statistically significant. Like that number is literally pulled out of the sky and I think a lot of people in research community say 5% is statistically significant but that p value can  

[00:31:23] ODELL:

can change. And the other tricky part is because the page one's blank,  

[00:31:24] Dan Gould:

And the other tricky part is   because the page ones blend in, it's hard for it's impossible for us really to collect data on exactly how many page ones there are. And by page join here, I'm not talking about the coordination. I'm talking about,   let's say common input transactions,   transactions that break that assumption and those that don't.   So it is,   it is a vibes based measurement, but if this is widespread,   if it's significant   to some degree,   then you do have   compounding   ambiguity in what happened in every transaction. Because if you like, if I'm doing the analysis, I have to make a guess. I have to say, I think there's a 5% chance, there's an n percent chance that these inputs came from different people and every hop along the way   that whether or not the input is linked to the output,   is is uncertain to me. The   probability compounds. Wallet fingerprinting is a different is a little bit different,   in general. So like some wallets will maybe use a certain unlock time or a certain script type   and you can follow   their activity   because you know this software only produces transactions   with this shape.  

But I believe in general   batching this stuff together   helps,   make those, helps   make those fingerprints less distinct because it's unclear what software is producing   what fingerprint. You got to go through the source code and like pull out what fingerprints this stuff is making. There's great work,   at ashana.com   about this, but that's What's that? Area improvement. How do you spell that? I shaana,   ashana   Com.  

[00:33:16] ODELL:

Got it.   I mean, part of that gets kinda solved   if the more wallets that add pay joint support. Right? Because that fingerprint is what wallet was used to construct the transaction.   So if that wallet was  

[00:33:30] Dan Gould:

has pay joint support, then it kinda solves that. And if all these things are plugged together in a big graph, it's very difficult   to find the cluster, the edge of the cluster. Yeah.  

[00:33:41] ODELL:

But, like, in a in a real world   scenario,   like, I think most Bitcoiners in our bubble don't realize that the number one self custody in wallet in the world by far is Trust Wallet by Binance,   which is an absolutely horrible Bitcoin wallet, but supports Tron and Solana and everything else. So many people use it.   And for instance, they probably have I mean, I don't know. I'm speaking out of my ass, but my guess is that they have a relatively obvious fingerprint when you do a trust wallet transaction.   I mean, for starters, I think they just reuse addresses. But   so if you were a user of that, then you're not getting any of the passive PayJoin   privacy benefits because it's very obvious you're sending from Trust Wallet. So in that situation, you're clearly not using PayJoin. Right?  



[00:34:32] Dan Gould:

Yeah.   You're   probably you're probably stuck with it. There is a limit to   how effective pay join can be. If you're if you're using the same address every time, even if you're   involved, you're not gonna be helped. There is basic hygiene   we need to   promote   at, you know,   devs and promoters in the space that people clean  

[00:35:00] ODELL:

up. So,   if I recall correctly,   there was a pay join   implementation   that might still exist, that was pushed,   that was that was implemented by BTCPay server   that I think Kooks was,   the maintainer of.   And they had, like, this concept of   I think he called it, like, a snowball   where, like, the idea was that if you're the receiver,   you could get fee savings   by using   transactions where you're receiving, let's say, you're a merchant and you could,   basically, consolidate UTXOs because the number one fee burden for transactions is   how many UTXOs you have on the input side. So ideally, if you care about fees, you want to consolidate UTXOs. But if you consolidate UTXOs, you have privacy loss. So why not use PayJoin to do that process for you so you don't have privacy loss, but you do have consolidation so you have fee savings?  

What is your opinion on that?  

[00:36:06] Dan Gould:

That sounds great. All of this PayJoin dev kit is built on the foundation that Kooks and Nicholas and the contributors to BIP 78 page join version one worked on. So it's totally backwards compatible   with that.   That protocol is limited because of the liveness assumption. It requires sender and receiver to be online at the same time. But for someone like a merchant, it's it still works. You lose a little bit on the metadata protection,   but it still works.  

[00:36:33] ODELL:

Yeah. That was my next question. Like, isn't it a heuristic itself, the snowballing? Like, isn't that kinda obvious on chain that that that's what you're doing and it's a pay join?  

[00:36:42] Dan Gould:

It   is, but it's no different really than if you're   making a peel chain by sending a small amount and receiving change and sending a small amount on that change the same direction. The way you get by that is by, batching some outputs or making some intermediate transactions.   But still,   even if you have this snowball,   all of the inputs to that transaction   might not necessarily come from the same person, and you might be making   a bigger   change. Maybe there's an amount that maybe there's a pay join out. It's hard to distinguish.   So you don't know if this snowball, the big ball is going as change to the sender   or the receiver. You don't necessarily know the direction. You might be able to make some assumptions about it, but I don't think it says   I don't think that problem is as clear cut to analyze   as some of the naysayers   might think.  



[00:37:39] ODELL:

It would it would probably have to be more of an active attack rather than, like, a passive attack looking back on the chain. Right? Because you could   you could do, like,   if you're thinking is a merchant using paid join in a Snowball, you can just do some transactions to the merchant, open up their BTC based server,   send some money, see how it flows. But that's obviously completely different than, like, looking back five years on the chain or something. Right? If you're second party to the transaction, if you are the sender, you can see the change.  

[00:38:09] Dan Gould:

That's   or you can see   the consolidation between the Yeah. You would know.   Yeah. That is a big issue that needs to be alleviated   and only can really be fixed if we have these multiparty pay joins where there are multiple senders and multiple receivers. Right now, because there's only two people involved, I know what like, if I'm sending money to you, I know what inputs and outputs are mine. You know what inputs and outputs are yours. Until we have another person involved, that's always the case.   I guess there's there is a caveat there, which is if you're the receiver,   you can make outputs that forward money to other people, and I don't necessarily know about that. But I Right. Would not rely on that strictly.  



[00:38:47] ODELL:

I mean   and you you have this I mean, the big issue there, right, is that   let's just use the merchant example again. Like, if a merchant's doing paid join   and I'm trying to   figure out their transaction graph,   they're disclosing   UTXO ownership   that they might not otherwise to me when they're giving me their input. Right? Like, is there is there, like, almost like a denial of service style? It's not really denial of service, but, like,   input harvesting   kind of information   gathering   attack that could happen there if you're  

[00:39:26] Dan Gould:

pulling Yeah. This is the inputs from the target. Probing attack in the literature. It's a probing attack. So   on payjoindevkit.org,   there's a blog post all about the probing attacks   that have been   discussed since the earliest days of this before even the first spec   by Ryan Hovar came out when he was trying to build a pay join protocol for   bustabit.   This is before HTTP servers, before p s b t's were even a thing.   This was talked about, and   it's mitigated to some extent by the receiver requiring   a payment in order to consolidate.   But, also, the receiver should only be consolidating   what they   are comfortable   consolidating. If I'm gonna pay, BTC pay server   and   they have some input that they never want to consolidate, they don't want their customers to know about. They're just never gonna consolidate that. If they were gonna consolidate it otherwise because they needed to make a big payment later, because they needed to make a big transfer   to an exchange to get some fiat,   that's the type of input you would wanna use anyway.  

PayJoin, like I said, it doesn't   make   any requirements   on   coin selection. That's all up to the implementing wallet   and   is   a problem to be solved   unto itself. We've got a research team working on these problems too, but they're a little bit outside of the scope of   the pay join coordination itself.  

[00:40:56] ODELL:

So when you say   require payment, the whole idea there is you you're putting a a cost to the attack. Right? So, like, they're gonna have to send you Bitcoin, and so they keep doing the attack to try know.   Did you really lose me? I still have you.   You don't have me?   I still have you.  

[00:41:21] Dan Gould:

I wish there was a way to post this to the live chat, the probing attacks paper,   because we just came up with this. Can you There's a big Can you not hear me? Can you not hear me? Kit.org.  

[00:41:34] ODELL:

Let's see.   Yeah. I think I lost Dan.   Live chat. Do you see me or Dan or both of us?   Leave   and   come back.   Live chat. Do you still have me?   We got Mav twenty one zapped 10,000 sats. We have Lido zapped 2,100   sats. We have chief white zapped 4,200   sats, and Madaroo zapped 1,111   sats.   We have space bear saying we see both.   I just thought I heard Dan rejoin, but I do not see him.   Let's see if he's texting me.   You   lost   me.   Rejoin.   Okay. He rejoined.   Let's see.   Dan, can you hear me?   Test? I see your Internet is, like, trash. And, oh, I hear you now.   I think it was your side, but who the hell knows? They're trying to stop the signal.  

Yeah. We can't   I don't remember   what we were talking about.  

[00:43:24] Dan Gould:

Probing attacks, mitigations.   Yeah. This problem has been around for years. It's mitigated. Basically, you require a government to receive money, and you always have that fallback broadcast. So there's a cost to you. There's a cost to it. Yes.  

[00:43:38] ODELL:

Yeah.   So that they'll run out of Bitcoin eventually if they're trying to   figure out your   UTXOs.  

[00:43:48] Dan Gould:

Yeah. And if they try to make the same request, if they have this Yeah.   Name puts you ban them. You just say, I'm not gonna I'm not gonna page one with you. Right.  

[00:43:57] ODELL:

Money.   Oh, because you have the fallback, so you can just just take the take the money.   You mentioned multiparty   input side   transactions.   Where do we stand on that? Was that a is that a six month problem? Is that a year long problem?   When   when when release?  

[00:44:27] Dan Gould:

So it's launched. We just launched one that lets you do multis   one receiver.   It's in   page one o dot 23.   It's on,   but you can use it.   In terms   of multiple receivers interacting, this is for, like, a year or two.   It depends.   So right now,   in terms   of implementations,   we can be take   off the shelf and integrated.   But to have all the testing and make the thing work really well, it takes engineers on both teams, on our team and on the to do.   We've got research too. I'm not sure. I'm losing connection again. Let me  

[00:45:17] ODELL:

We can kinda hear you. You cut in and out a little bit.  

[00:45:33] Dan Gould:

Yeah. They actually,   they're where this   It requires Do you sound   the trickiest part.  

[00:45:46] ODELL:

Try turning off your camera.   You're all popcorn y for us.   Well, it was a great rip.   I think we lost him again.   We've lost him again.   What's up, freaks?   You have any questions for me while we're waiting for Dan to come back in?   Lightning q and a.   Oh, here comes Dan.  

[00:46:25] Dan Gould:

You told me Adam back for fifteen minutes, so I figured I'd just play with my network connection and see what I could get away with. You look clear as day now. Did you change something?   Yeah. Change networks.  

[00:46:37] ODELL:

Oh, there we go. Okay. We're back.   Back in business, freaks.   But we were talking about multi party.   You said we have it under an experimental flag.   Basically, the bottleneck is we have to you have to work you guys have to do work on your side, but then also the implementers have to do it on their side. So there's, yeah, there's there's two things that page one dev kit is working on mainly. We're doing  

[00:47:01] Dan Gould:

Page one integrations. Like, we have to get this thing out into the world, and we have research.   And   right now,   almost all of our research effort   has been shifted over to implementation   because   it doesn't make sense for us to come out with this v two protocol and then just immediately   work on, this async protocol and immediately work on the multiparty protocol, then nothing ever gets done. We have to actually prove this stuff works. So we got in Bull Bitcoin.   We've made some proof of concept for Bolts and Liana.   Like, we've shown this stuff works, but we need   it's a big effort   to get this stuff working with wallets in a way that someone   is comfortable putting big money through.  

We've got QA now. We've got a person that's just   shout out Ben Allen   for chomping away at the bit there, just making sure stuff works.   As we roll those out, we'll be able to focus more on both the multi party protocol and then the development in the kit so that anyone that's already in integrated this integrated page one dev kit can just flip a switch basically and turn on   multiparty.   But right now,   yeah, we're doing the we're doing the integrations,   and we have more people asking for the integrations   then we can   build quickly. That is the the biggest bottleneck.  



[00:48:23] ODELL:

Got it. Okay. That makes sense. And how I didn't ask you. How is the communication handle? Is there, like, a coordination server or something? Does   does the exchange run the coordination?   How does that work? There's  

[00:48:36] Dan Gould:

two servers involved. We use something called oblivious HTTP. So the async pay join spec, like I said, has these mailboxes,   and anyone can run a directory server that has that hosts the mailboxes.   Right now, page join dev kit hosts one, and we just came up with a way for anyone to host one to be reachable by these oblivious HTTP relays. So   why are we using oblivious HTTP?   Because the directory shouldn't need to know about your IP address.   To do that, oblivious HTTP   enforces that there's a proxy in the middle that's one of these relay servers.   And up till this point, those have mostly been the wallet service providers. Because if you're a wallet, you probably already know your user's IP.  

You may not. Some of them, like, cake really let you dial in all the you can have your own Electrum server. You can have your own node, but not everyone does that. Sparrow  

[00:49:29] ODELL:

refuses, like, Craig Raul will never run a server.  

[00:49:33] Dan Gould:

Yeah. Yeah. So   you can just plug in either one of these standard servers as your configuration. Well, your the oblivious HTTP servers are really the configuration. You choose who you wanna proxy to, and you can reach a directory which is defined by the receiver.   The the the receiver says, I'm listening at this mailbox. Talk to me here. And you communicate to that through one of these proxies   using   o HTTP, oblivious HTTP.  

[00:49:58] ODELL:

Got it.  

[00:50:01] Dan Gould:

That makes sense. It's a web standard. Apple uses it for their private relay, so that's really where it came from. It's this it's a standard that is becoming   ubiquitous. I mean, even it's in Firefox for oblivious HTTP,   like, DNS over oblivious HTTP.  

[00:50:19] ODELL:

It's getting all over the place. And for the end user, like, 99%   of end users will have no idea   that this is really how this is working in the background. That's the whole point. Yeah. Scanning a deposit address and   pressing send.  

[00:50:33] Dan Gould:

Yeah. It's like two hop tour. So if that directory server and the relay colluded,   then they could match the IP address   to the two people   communicating.   But, otherwise, the directory just knows it's talking to proxies, and clients just know they're talking to proxies in one directory server. They never learn each other's IP addresses, and the directory server doesn't have enough information to know that two IP addresses are talking to each other.  

[00:50:58] ODELL:

And if the user wanted extra protection, they could   use a VPN as well or a Tor. Yeah.   Yeah. Okay. That'll make sense to me.  

[00:51:08] Dan Gould:

It's all about raising the bar on the default. That's everything we're doing is about making the default way, the convenient way, have a minimum   privacy.  

[00:51:18] ODELL:

Right.   What do you say to the user that maybe   for privacy reasons only   pays merchants   or deposits to exchanges   using Lightning?   Should they keep doing that? Should they switch to pay join if their  

[00:51:38] Dan Gould:

merchant or service supports it? How do you think about that? Doing that? It depends. Are they this is someone that's not interested in self custody?  

[00:51:48] ODELL:

Why? Because you can't self custody lightning.  

[00:51:51] Dan Gould:

Well, the thing is if you're doing lightning self custody, you probably need to move coins around from time to time. And in those cases,   you can use pay join with the lender. Yeah. They solve different problems. I think they're Yeah. Compatible. That's everything we've built has been as a building block too. So PayJoin plugs into the existing infrastructure.   It doesn't try to push people out of the way.   It makes the lightning network Got it. Have more privacy because the   analysis of the blockchain   gives you even less data into what's going on on the Lightning Network if Page one is being used,   if fewer assumptions can be made about what,   what channels have   what channels are related to what clusters.  



[00:52:38] ODELL:

Right.   Would you consider is so a lightning channel open is   a two of two multisig between you and your channel party,   where both   both both parties are providing inputs to the transaction. Do you consider that already a pay join, or is that just like a semantic thing? I I think it's a semantic thing, but I don't think it hurts to think about it as a pay join. It definitely breaks  

[00:53:04] Dan Gould:

the common input heuristic.   Well,  

[00:53:08] ODELL:

not really. Not really. Right? It's like those  

[00:53:10] Dan Gould:

it's like two person common in Yeah. I guess the output puristic. It's like those two people have the same But the output of the channel when you close the channel, you don't know which   output that's made came Is who. Who. Exactly.  

[00:53:22] ODELL:

Yeah.  

[00:53:23] Dan Gould:

So it does break it in that way. Yeah.  

[00:53:27] ODELL:

Yeah. Like, unless you're doing active surveillance on the lightning channel Which I the best. I think it   is is Group probing.  

[00:53:35] Dan Gould:

Assuming that that's being done if you want any privacy guarantees. But probably isn't.   You should assume it, but it probably isn't for most people's channels. In the inputs, you know who's participating in the channel because that's all broadcast information. Right?  

[00:53:51] ODELL:

Right.   But you don't necessarily know   unless you're actively probing, you don't know. Balances of the channel?  

[00:54:00] Dan Gould:

The yeah. The active balance. Yeah. That's a good point. So that that   helps   create that ambiguity between which inputs and outputs are connected at the end of the channel close.  

[00:54:12] ODELL:

Area so I guess to the   the next part of that question is, like, there's probably a scenario where we could have multiparty,   like, more than two people pay joins for channel opens for Lightning too.  

[00:54:25] Dan Gould:

Right? Yeah. Absolutely. And I think even before we get to that, there's something in terms of convenience that is a reason you might wanna use pay join. So, like,   I'm funding a lightning channel for the first time. I have some coins on a non lightning   wallet, I wanna put them into the,   node with a wallet to open channels,   I would typically have to communicate using the chain, which is annoying and leaves a fingerprint where I'd send my funds into the lightning nodes single sig wallet, and and then I would create a multiparty channel. But instead, if the two wallets can talk to each other,   I can just send a fallback   message to my node saying, hey. I wanna send you money. Do you wanna open any channels? And you manage both sides, so you're just gonna say, yeah. Open a channel.  

That's gonna   construct the transaction that actually opens the channel, put it back to your wallet, say it's an exchange that supports PayJoin.   They'll still sign because it's the same amount of money, and it's authenticated   by the receiver.   And then that one   transaction funded from an external wallet can fund your channels, and it could even splice in perhaps. It it's really just a matter of sending messages   back and forth. Adding that little bit of interaction where we can lets us build all sorts of these cut through transactions.   Another one, like, we just proved was possible was with the Liana   inheritance   refresh. Do you mind if I talk about that a little bit? Let's go for it. Yeah. So   Liana   has this   degrading   time lock.  

And after the   so your coins are in this   in this time lock where after, say, ten years pass, then someone else   can spend your coins.   And the reason you would want this is, say, you die. Like, you want someone to be able to recover your coins, but you need to consistently refresh that,   especially if you wanted someone to have the access access to the money sooner, say, like, within six months if they wanted to, you know if they had some payments to make to clean up your estate.   So when you receive a pay join to one of these wallets,   it can   say, don't just create a new coin   with this policy.  

It can spend all of the coins or some of the coins that have this policy and refresh the time lock in the same transaction   that it receives from an outside wallet.   So this is less privacy focused until all of this stuff is tappered and difficult to see the policies.   But still, we at least   that, that refresh can be an automatic user experience where every time   that user wants   to increase their stack,   they're refreshing their time lock at the same time so they don't have to worry as much.  

[00:57:16] ODELL:

Every time   I'm   adding DCA to my cold storage or whatever, it would refresh my time lock, which in Yeah.   Otherwise, it wouldn't. Otherwise, you'd have to send another transaction.  

[00:57:29] Dan Gould:

Right.  

[00:57:30] ODELL:

That makes sense.   And so specifically to the, I mean, I don't know how you made it this far, but   to the, to the, to the freaks that are listening that maybe are a little bit confused   about that Liana,   example is it's using mini script and time locks, and you have to constantly refresh it. And the whole idea   and just correct me if I'm wrong. The whole idea there is   when that time lock ends,   it goes from, like, a multi sig to a single sig, and so you can use it in, like, an inheritance type of situation where   your air only has access to the single SIG.  

And so that your air can't rug you unless you stop refreshing your time lock because otherwise your air is in your threat model. Right?  

[00:58:13] Dan Gould:

Yeah. Shout out to Armin Saburi and,   Arthur for getting this out last weekend. They did this in the weekend. I have no idea. I don't know. It was nuts.  

[00:58:23] ODELL:

I think I'm going to have,   Rob Hamilton on the show   in the coming weeks. Who's, one of the preeminent manuscript influencers,   and cofounder of Anchor Watch, which has their Trident wallet. And I think, I mean, do you know, are there any other mini script wallets between Trident and Liana? Are those the two?  

[00:58:44] Dan Gould:

I don't know. I know you keep pushing Rob to open source his stuff and he's really missing out.   If he was open source, we would have done it on anchor watch. This would have already been done.  

[00:58:54] ODELL:

So you heard it you heard it at the MIT,   Bitcoin Expo in person,   me pressuring him. What'd you think of MIT?  

[00:59:05] Dan Gould:

That was I've been to those expos since I think 2018,   and that was the best one. I think partnering with HRF   to make it about FreedomTech   completely changed the vibe, the content, people that were there.   I I really enjoyed doing the hackathon.   I liked when Roger   Zingledine talked about Tor and how   he communicates with the larger world about how,   this is a necessary piece of infrastructure.   Yeah. Overwhelmingly positive. I was really stoked to have that happen.   Yeah. I was gonna say HRF  

[00:59:41] ODELL:

HRF   being the signaling mech it was HRF to me being involved was a signaling mechanism that it was gonna be,   more high signal and worth my time coming out for it.   And I, I couldn't agree more. I, and I mean, the, the currency initiative too. Like that's been around for a while churning research out at the same time. But in the past, in the past has been more like crypto blockchain stuff. Right. And, like, this time was, more focused on Bitcoin.  

[01:00:08] Dan Gould:

Definitely.   People showing me Flexa and Algorand last time I was there, I think. Yeah.  

[01:00:13] ODELL:

I,   yeah, it was a high signal group that were there. I mean, I was,   fanboying a little bit on some of the Bitcoin I won't name names, but some of the Bitcoin developers that were there. When I saw you on stage, you were like, oh, man. I'm getting imposter syndrome speaking at MIT. What? Is so cool? Well, my mom was watching the live stream. I was I almost said, look, ma, I made it to MIT,   because there's no shot. There's no shot I would've gotten in, when I was applying for colleges. So,   it definitely definitely felt that way. It felt a little bit unreal.   You know, the back the background for my,   calling out Rob for the open source   was I was making my deck, and I was gonna put a slide in there about   how there's this beautiful, sustainable   method of maintaining open source software, where you have a company like Anchor Watch, and then they have their open source,   software stack Trident wallet that's available to the world, but then they monetize it through Lloyd's of London   insurance.  

And, and there's, you know, it's, it's, it's beautiful because you don't have to rely on grant funding or anything else. And I'm like searching around for their license for Trident wallet.   And I'm like, oh, this is not open source. This is just scratched it from the deck.   But yeah, one day I think it's just an order operations thing. I think they intend to,   fully open source it.  

[01:01:42] Dan Gould:

Yeah. And that brings up something else, which is, like,   why we're operating as a dev kit like BDK or Yeah. Lightning dev kit that's grant funded. I think   we've seen that the sort of privacy wallet   idea   is   dead as   a funding source. It's too high risk and there's also this problem where all these shortcuts are made to get a product out that Right. Has military grade encryption or whatever. You just say whatever you need to secure a bag, and the incentives are not aligned to actually serve   the   users to bring the privacy up. And we get at these local maxima too where it's like, okay. I have the monopoly business. I'll focus on telling everyone that my thing is the best instead of fixing any further problems. Cause there's just no incentive for me to do that. And I think that's changing, which is welcome, but it's difficult.  

[01:02:33] ODELL:

Yeah. I,   yeah. I mean, we kinda saw that with both Wasabi and Samara last cycle where they're like, we've solved Bitcoin privacy.  

[01:02:44] Dan Gould:

And it was not solved. Like, I didn't recommend that stuff to people. I wasn't like, yeah. Go use that because there's too many ways it can go wrong.   HRF can't tell people, like, go and use   Whirlpool. You'll be safe for sure. It's like, no. Not the case. No.  

[01:02:59] ODELL:

The bigger issue is is the regulatory   exposure of taking a cut of   even if you're not taking custody, taking a cut of the flow of transactions   seems to be where a lot of   the regulatory targets   come from. From their perspective,  

[01:03:16] Dan Gould:

I think so. I don't know if that's actually the   legal circumstance, but I think   that's where the regulator gets upset because they're like, you're a person. You're making money. You shouldn't be doing this.  

[01:03:27] ODELL:

Yeah. Like, clearly, you're involved because you're making money from people using the   tool.  

[01:03:33] Dan Gould:

Yeah. But, like, signal people are involved using signal, and we don't, like, they're not going to jail for But it's donation based.   It's value for value. You can use it for free. WhatsApp then?   WhatsApp has encrypted messaging. Is just spyware.  

[01:03:47] ODELL:

Yeah. I mean, they're fine with that being encrypted. Like we've been able to get to the, they're getting all the metadata   though. They're just getting all the, there, there was a handshake deal that happened there behind the scenes. It was like, yeah. You know, it's if a hunt, if 1,500,000,000   messages are going through WhatsApp, we can let them think it's private. And they also do, like, clear text backups and stuff. Like, that's,   WhatsApp is a dark pattern. Like, I hopefully, we don't emulate WhatsApp. I think signal is I to me, signal is one of these massive wins.   This this successful independent   relatively sustainable   donation funded open source privacy project.  

I think it's harder you know, it it helped that there was, you know, a couple billionaires involved   in making sure that it's funded. Yeah. And, I mean, some of them are the same, like I think Dorsey doesn't get enough credit.   He took tech secure   into Twitter   and let them let which was the precursor to signal and then let them   spin out signal   as a nonprofit entity with, without, like, taking any IP or anything.  

[01:04:57] Dan Gould:

Like, he, like, birthed it to a degree. Yeah. It takes these live player actions. Encrypted DMs. What? It takes these live player actions. Like, this stuff doesn't just happen because the incentives are set up right. Like, people actually need to make moves.  

[01:05:11] ODELL:

So I heard you talking to Nifty about this. Yeah.  

[01:05:14] Dan Gould:

Yeah. It's tricky. How do you get the model right?  

[01:05:17] ODELL:

I bet there's no perfect model. It's   I mean, it's,   you know,   the real world is difficult. I   I so I'm curious. So, like, how is how is paid joint dev kit funded right now? What is your current funding situation?  

[01:05:36] Dan Gould:

OpenSats.   Shout out, Odell,   and Spiral.   I'm trying to think if we have   income from other play. I think that's the those are the those are the two right now. So it's   individual   grants   for the most part at the moment, but   stay tuned. If you're a business who wants to see this in the world,   get in touch. We'll make an integration happen, and we'll take this to the next level. That's what I'll say for now. So what I think is, like  

[01:06:07] ODELL:

and that, by the way, that wasn't a setup. There's I like   it's hard for me to keep track of Yeah. Yeah.   Of of who we're actively funding and who we're not. I said to someone the other day, I was like, you know, I'm really proud that we're funding you. He's like, my grant ended, like, four months ago. Like, you guys didn't renew me or whatever. I was like, well, I did you know, I wasn't being I wasn't trying to be a dick.   Because   it's way bigger than me at this point. I mean,   we have,   Gigi himself is just a quiet warrior.   Then we have some part time people there, but then at the end of the day, we have our nine person volunteer board, and then we have a bunch of volunteer committee members that are reviewing stuff.  

And it's just,   it's a full time job in itself.  

[01:06:51] Dan Gould:

I I gotta give HRF a shout out to Because Human Rights Foundation had this bounty at all last year that They're great. That we   were able to secure with this Bold Bitcoin   integration as a team.   So and they've helped us from the very beginning since, like, 2021,   I got a tiny grant to   work on PayJoin,   and that was before any of the dev kit existed.  

[01:07:14] ODELL:

Thank you, HRF.   Doing great work. I   and we do a lot of cross, like, co grants with them as well.   I,   where I was going with it, I just got a little bit sidetracked,   is   I think   an interest just talk about business on air. I or not business, open source projects on air. I think,   the model that Cashew is doing   is an interesting model where they spun up and BDK is doing it as well, where they basically spun up their own foundation.   I guess BTC pay server also   Mhmm. Where they spin up their own foundations and then they take grants into that.   And then they take actual independent donations out of that. And then they can pay   all these different open source contributors and they have more focus. Like, they know   it's hard. Like, for instance, it's if if if PayJoint DevKit ends up having   20 contributors that are focused on different aspects of the project, it's really hard for an organization like OpenSats to be able to determine,   you know, where money needs to go and and how how best to place support. But if you have someone like   Cali running the Open Cash   Foundation, I think it's called, but it's called Open Cash.  

He knows where the contributors are, where support needs to happen, and you can, like, greater focus   the donate. And I guess that's kinda what signal does too. Signal's probably a little bit more centralized.  

[01:08:48] Dan Gould:

We have plans here. Stay tuned. Okay.  

[01:08:51] ODELL:

Well, if I can be helpful at all, let me know. You already have. Awesome.   I got nothing else. Do you have,   do you have anything else you wanna chat about before we wrap?  

[01:09:05] Dan Gould:

This has been great.   This has been really good. Yeah. Thanks for having me on.  

[01:09:11] ODELL:

I guess oh, yeah. One more thing.   So like what's, what's the next steps here? Like there's people that are listening that are like founders of companies. There's people listening   that are users of,   customers of businesses,   users of wallets, maintainers of wallets.   Like how do we, how do we get paid, joined in every wallet,   every, every   exchange? Like what, what is, what is the next steps? What do you want to see from the community? Yeah, we gotta, we gotta do these integrations. So you mentioned foundation we've got, I think,  

[01:09:43] Dan Gould:

four people   full time right now and one part time. Like, people are working on the development kit actively. We've got these integrations out. We need people to own those.   If you   are a if you want to integrate PayJo and come and say hi and   use the dev kit. At this point, it's got bindings. It works in Python,   Kotlin, Swift.   We just did WebAssembly, so it'll work in the browser.   We can adapt it for Go and c sharp pretty straightforwardly.   Like, we need we need hands   to plug those in.   That's the main thing. If you wanna get involved in research,   once a week on Fridays, we have a study club in the   pay join discord, which you could find at payjoindevkit.org.  

We've got documentation   being written and blog posts.   People need to understand what's happening, but, primarily,   those integrations   need to happen. And   with   the if you're a commercial entity, if you're an exchange, that is probably where the biggest impact can be made. If you can get   if your exchange supports this, you can do the cut through, you can get the savings, and you can protect the privacy   of your users.  

[01:11:01] ODELL:

Awesome. You said if someone wants to integrate, they should come say hi. Is that payjoindevkit.com?  

[01:11:06] Dan Gould:

Or how do they send that? .Org. Yep. Or github.com/payjoin   is where we are.   That would be the thing.   Because my my contact at bitgool dot com.  

[01:11:18] ODELL:

Love it. I'll put all those links in the show notes. Dan, thank you for joining us. I think, you know, maybe   six months to a year, we'll do   a, pull you back on and see where we're standing and do an update and just keep pushing. How do you think about that? Awesome. Well, thank you for joining us freaks. Thanks for joining us in the live chat. You make it special.   Appreciate you all for supporting the show.   I'm not sure when the next show will be, but if, if you keep track on Noster,   I'll keep you guys updated. We got some   good conversations in the works, but love you all. Stay humble.  

Thanks.