CD199: CRAIG RAW - SILENT PAYMENTS AND SPARROW WALLET

Happy Bitcoin Monday, freaks. It's your host, Odell, here for another Citadel Dispatch. The show focused on actual Bitcoin and freedom tech discussion. How's it going, guys? It's a Monday morning, and we are off to a great start. It is seventeen hundred UTC right now, April 13 Monday, April 3.

The Trump announced that the US military will be blockading the Strait Of Hormuz to complement the the Iranian blockade on their side, And Bitcoin is somehow sitting at $72,276, which I feel like is a good sign, but we shall see. The current block height is nine four four nine one six. The current stats per dollar is one three eight four. And currently, one Bitcoin can buy you a little more than

15 ounces of gold. We've been tracking that conversion price, and that has been on a bullish trend, I have to say. So we'll keep watching that. Anyway, freaks, as always, dispatch is supported by viewers like you. Thank you guys for sending your scare stats as donations support the show. We have no ads or sponsors, just you guys. Top zaps from last week, our Fediment update was open mic with 22,222

sets. So Justin O'Dell, how about a live sale dispatch in Minneapolis for the next half year Federment check-in episode? I like that idea. I've been trying to make it to the Minneapolis meetup for a while now, and I need to make that a reality. I love how you guys hosted at the O'Shaughnessy Distillery, a Bitcoiner owned distillery in Minneapolis. So I will try and make it out there. I know it's one of the best meetups in the country. And then stimmy, 40 HPW, Zap, 21,000 SATs.

As always, freaks, all relevant links are still at dispatch.com. If you don't have stats to spare, sharing with your friends and family really does help search still dispatch in your favorite podcast app. Open up their phone, search it in their podcast app, press the subscribe button, and who knows? Maybe they'll get some little bits of wisdom that they weren't expecting. But anyway, freaks, I have a great show lined up today.

Ride or die, good friend, massive return guest, been on the show a million times, maintains the best Bitcoin wallet in the world. There is no second best.

Craig Raw of Sparrow Wallet. How's it going, Craig? It is good to be back, Matt. It is going well. I'm excited to be here. Excited to have you. So, I mean, Sparrow is the best. I don't we but you keep shipping. You keep shipping and you keep improving it. And the latest improvement you've made is a big push into the silent payments

support path, which is something that a lot a lot of us have been tracking for a while. I guess a good place to start is what are silent payments and why should people care? Yeah, great question. You know, silent payments are a way to have a static payment code. What is a static payment code? It's just a bank account number that you can pay, and you don't have to go and get a new one every time you make a payment. Right? So that's something that Bitcoin has never

really had in any widespread fashion, as we know. We always have to go and get a new address, at least most people do, in order to pay somebody, in order to do that in a private way. You know, you'd always Right. Consider I'm sorry. I'm gonna try and not cut you off much, but we kind of have always had it now because I mean, a ton of Bitcoin payments are made to just reuse Bitcoin addresses. It's just, it's really bad for privacy if you do that.

Yeah. No, that's right. So do it in a privacy preserving way. That's really the difference, right? That's what you have to do. So, you know, if you look back at what the white paper said about these things, it had a section about privacy in it, and it mentioned this issue of address reuse, but effectively left it unsold. And it's one of those kind of unsold issues that we've had to try and address ourselves.

What we're trying to do here is have a way to not have this back and forth every time. Because if you have the back and forth, you basically have a situation where convenience is not aligned with privacy. And as you and I both know, Max, whenever you have convenience not aligned with privacy, privacy is the one that suffers.

So, what you need to do is to have it so those two things are aligned. So, it is both convenient and private. And that's largely what we try and do. We try and make sure that those things are aligned so then people just use stuff automatically rather than trying to fit their lives around the tech. So, Silent Payments is really just the most recent version of trying to solve this particular issue.

And I think it's quite a compelling one. But in order to really understand, I think, what it is, one has to kind of take a step back and look at the history of how we derive addresses in Bitcoin wallets, how we've done that in the past leading up to today. Okay, so let's do that.

Okay, so the first way in which people and indeed Satoshi himself or herself did that was to basically derive a single key. So you basically take a secret and then you derive an address from it and then you can pay that particular address. But of course, that's just a single address system. So you can certainly pay to that address again, but as you mentioned, Matt, you then end up with privacy impact.

So what people started doing is they'd have like a bag of these single key addresses, which they then have to have some management system on their side, some unique custom system to manage. And that was the early way in which it was done for quite a while, actually, many years. Now, in 2013,

we had the first major upgrade to the system, which is still a commonly used system in place today. And that's called an HD wallet, and it was specified by a BIP called BIP32, and it effectively creates this kind of tree that you can think of it like a folders, and you can create as many folders as you like, and then you can have files in those folders. And effectively what we have are these long chains of addresses

and that gives us or gives the wallet rather the ability to create a new address at will. And the idea was right, so now it's cheap to create addresses and we can keep track of them all and we can restore them all from one seed.

And that's really a massive step forward. And it was, it was a huge step forward. And that's, you know, the reason that it is the system that we use today is why it survived for thirteen years and will no doubt be in common use for many years to come. So the HD Wallet is great, but it has a big downside in that it does not enforce unique fresh addresses, right? It sort of leaves it up to the user. So if you're a new user, you get an address, you withdraw, say from an exchange,

and then it arrives in your account. You now have this idea that that address is a trusted address. It works, right? And you tend to reuse it. You tend to say, Well, that one is useful to me. I'm gonna just send to it again. You might've heard that you shouldn't reuse addresses, but typically that advice gets ignored by newer users. So, something that is not well tracked in the Bitcoin ecosystem is address reuse.

But I did find some evidence on it and it looks like it's around 25 to 35% of addresses are being used. So it's way higher than you might think. I mean, I don't have up to date stats. I actually have someone working on that, but Well, Yeah, lines up sorry. No, it actually went as high as 50% during the 2021 bull run. So, you know, and that's not just affecting the people who reuse addresses, that because privacy on a public blockchain is kind of a common good, it affects everyone.

And your privacy is worse because other people reuse addresses. Sorry, Matt, you're saying? Yeah. If like 50% of people are reusing addresses, then like the way Bitcoin is tracked is based is through probability analysis

on change of ownership. And so that makes that probability analysis obviously much easier because you can narrow down when ownership changes even if you are not reusing your own addresses. What I was gonna say is it actually kinda makes sense to me, at least directionally, that it's that high for two reasons. First of all, the number one self custody wallet in the world is Trust Wallet. I I

think they default to a static address. They did for a while. I don't know if they changed it. Also, in shitcoin land, that's just the common flow. Like, in Ethereum, you have you get your Ethereum account, which looks like a Bitcoin address, basically.

And, like, that is always what you use. You use the same one over and over again. So anyone who's coming over from shitcoin land will be used to that UX flow and will do it. Obviously, it puts no risk at funds being lost. It is the easiest way to use Bitcoin. And unless you kinda go out of your way, then people tend to reuse addresses. And I'll use an example partially why I'm so excited about selling payments is with OpenSites, we're sending out a multisig transaction

once a month to about 200 people. So that's 200 Bitcoin addresses. The lazy way for us to handle that is when they receive their grant, their one year grant paid out monthly, they give us a single address, and then we would just send it to that same address every month. Now that's horrible for privacy.

So we go out of our way not to do that, and we have to get a new address from them every month. To be clear, we usually in the beginning of their grand say, like, send us 12 addresses at once, and we'll send it to a new one every time. But you can see how logistically that becomes a real pain in the ass. We have to audit the transaction, make sure all the addresses are correct, and make sure the right amounts are being sent.

While strictly speaking, if we just had single address that we could send to every time, it would be much easier. Yeah. And as you were saying, just because if you're listening to this podcast, almost certainly you are not reusing addresses. I think it's, you know, and I think it's easy to assume that, you know, because everyone around you is not reusing,

then there's not a lot of reuse, but actually it's really quite high. You know, just think about an exchange. Generally with an exchange, you have to kind of go through this process where you register an address that you're gonna withdraw to and you know, the whole system is almost set up in order to encourage you to reuse addresses rather than the other way around.

So, you know, the HD wallet system was a big step forward, but it's really not getting us to where we need to be. We need to take another step forward. And the first attempt to move beyond that was in 2015

with the arrival of BIP 47, and I'm gonna just skim over some kind of earlier attempts there because BIP 47 is really, I think, the first major attempt to kind of move beyond that. Now, BIP 47 is still a contender today. It's still around and it's still being, you know, you can still use it in Sparrow, you can use it in Ashigaru, many other wallets. Blue Wallet is one. What BIP47 has is this notification transaction, which is quite well known for, and that has been criticized

for various reasons. I don't actually think it's a major issue. Personally, I think that the cost of setting up a notification transaction, which is usually the most immediate reason, is actually pretty low. It's about a thousand sets, not a huge amount of money. There is a linkability concern, and I think that that's valid, where it's not the payment that you send that can be linked, but it is the notification transaction,

the input sending to that notification transaction and any change that might be spent out of it, that then can be tracked. And then you can see some degree of a payment graph, not how much you're paying, but who you're paying as a result if you can track those particular inputs and outputs. Like you would know you would know that I

me and you are paying each other, but you wouldn't know when we pay each other or how much we're paying each other. Right? That's right. So if you were able to track, if if you were able to see, oh, I used the change output from sending to a notification address and I saw, oh, that's Craig's change output. I managed to figure that out somehow. Then I can see, oh, Craig made a notification

transaction to Matt. I know that he must have likely paid Matt in the past. That kind of thing is not ideal. It obviously does harm privacy in some way. But actually these issues are not in my view the major reason that Bit forty seven hasn't gathered kind of widespread adoption to date. I think the major reason for that is actually that it doesn't support hardware wallets. So something which is not I think well understood

is that in order to derive new addresses in BIP 47 wallets, you need to have a private key of that wallet. So something as basic as just deriving a new address, which is something that a coordinator has to do, not a hardware wallet requires that private key. And it was invented in an era where hardware wallets was just not a big thing. As a result, I don't think it really took that particular need into account.

But we're obviously living in a world where Bitcoin is predominantly used as savings tech, and most people are not prepared to put their savings onto software wallets. So as a result, you just have this natural resistance to adoption of this new address system. And I think that that for me is probably the major reason we haven't seen a lot of uptake of BIK 47 to date. Makes sense.

So, you know, since then, we've obviously been trying to push that forward for a long, long, long time, hasn't really gone too far. And I think what's happened in the last few years is we've seen some new contenders come. And I think the major one of those is the one we're gonna talk about today, which is silent payments.

So silent payments, and you know, the way you can think about all these address systems is how can you arrange the cryptographic operations in such a way that certain elements emerge as natural characteristics? That's, if I can frame it in that way, that's kind of what they're all doing. So they're all actually using fundamentally the same very basic mathematics

underneath, but they just arrange it in different ways. They put the data in different places and they compute that data at different times in order to derive, you know, how, what the emergent characteristics are. So, silent payments is not doing anything mathematically which is new. It's just using very standard maths, very standard cryptographic stuff, which has been around, you know, for decades or more. But it's doing it in a different

way. So what silent payments does is it takes all the list of pros and cons and optimizes every single one of them to be the best it can be, except for one, except for scanning to receive payments. And on that one, it just says, right, we're gonna make that one really tough, but on all the others, we're just gonna ace it. We're gonna be like a green tick on all the others. We're gonna have hardware wallet support.

We're going to have enforced, you know, fresh addresses all the time, you can't have a reused address. We're going to basically do the best that we can in every way you can measure an address system except for this one thing. And that's, I think the right way to kind of see it, because when people have pushed back on silent payments in the past, it's usually

on that scanning cost. And I think, so I think that that's, yeah, as I say, the way in which I would view these different ways of being able to derive addresses. I mean, to be clear on the hardware wallet support piece, the cool part about silent payments is basically

the hard hardware wallets are agnostic to it. They don't even even realize that silent payments are being used. So they don't have to do any kind of changes for receiving on the hardware wallet side. On the sending side, that's not the case, though. Right? On the sending side, there needs to be some changes in order to be able to like pay a silent payment address?

Yeah. So so there's there's actually a a number of different bips which have come out. So there's two two bips which specify how to send to a silent payments address, and they're basically just additional PSPT fields that the hardware wallet needs to be able to read. And then there is one additional BIP, which was actually only merged last week. So this is brand new, BIP three seventy six, and that specifies how to spend silent payments amounts that you have received.

So with those two BIPs, we now have a complete hardware wallet specification in terms of PSPT fields and how to treat them for hardware wallet support. So, you know, this is all brand new, but these are well reviewed BIPs by, you know, lots of people and that gives us the ability to be able to support to support silent payments on a hardware wallet level. Got it. So, we will need the hardware wallets to do updates, right, in order to have full support? Absolutely, yeah, yeah.

So, let me return now this kind of key issue. So, just wanna kinda iterate the main benefits of silent payments again. One, we get the static payment codes, which we need, right? You don't have to do the back and forth interaction for every new payment,

right? So that's perhaps the most important obvious thing, but I think almost more important, I mean, it's kind of the same as the fact that you have enforced fresh addresses every time. You have no more address reuse. And I think that that's just a massive win for Bitcoin privacy on a broad level. If we can transition to this new address system,

we all get more private Bitcoin as a result. So, you know, you might be thinking, why should I care? Well, this is why you should care, because if you adopt this and you encourage others to, well, you get more private Bitcoin as a result. And then finally, for the more technical people will be aware of this thing, which is kind of inherent to HD wallets, something called the gap limit, which is how far ahead in the wallet it searches for new transactions.

So we talked about that chain of addresses that the HD wallet has to create. It doesn't know how long to make that chain. So it says, well, I'm gonna look a certain amount forward. If I don't see an address with funds in it, I'm gonna stop. And that thing is called the gap limit. It is an issue because with a BDC pay server instance today, you can request a new invoice, you can not pay the invoice, you can go on and do that twenty, thirty, 40 times and suddenly

any new amount sent to an address further down the chain just aren't seen, because the wallet doesn't know to look that far. So you have these kind of issues which really are very much non ideal and create a lot of friction in the Bitcoin payments ecosystem. So those are the major things, but silent payments removes the gap limit, it's no longer a thing. And that just makes wallet development much, much easier. So, you know,

going back to the reason that we don't have silent payments today, right? It's

obviously better in every way, except for one, except for this scanning cost. So the way in which the silent payments BIP proposed to actually improve on this was to say, well, we can do live client support, we can use compact block filters, and we can basically reduce the amount of data that we need to scan by taking the entire transaction and saying, well, we can compress that down to a single key of information that we actually need. And that's called a tweak.

So you basically go through the entire blockchain and you say every single transaction that could have spent to a silent payment address. In other words, the inputs were right and the output was going to a taproot output, it had at least one of those. Can then say, okay, well, let's reduce that transaction to a tweak. And then we go and we can scan that long list of tweaks and we can do our computations on the tweak.

Now that asks the client to download all the tweaks, run the scanning, and then download the blocks using compact block filters. That is a lot of work. And let me tell you that is a great deal of work to ask any client to do, let alone a mobile phone. And if you've tried to use silent payments before, you've probably

had an experience which was not ideal. And that's basically the reason why, because all of the early client implementations use this particular approach, which requires downloading a whole lot of information to begin with, then performing this really expensive compute on that information. And then on the basis of the outcome of that compute, downloading the blocks and extracting the transactions that are paid to you from those blocks. So you can Is this okay while it does it?

I believe so. Yes. I'm not actually sure exactly what their method method is, but yeah. I believe this is what what But like when you try to do with Cakewallet, like the scanning just takes a while. Like it's just like it eventually shows up, but it's that's the trade off, right? It's like you're basically, you have to have the app open for a while while it's scanning everything.

Yeah, so I kind of did a little test with Cake Wallet and this is not a scientific test, but I had to catch up around two years and I figured at the current rate of scanning, it was gonna take me around nine hours. That figure may be a bit out, but it is a more or less directional figure about how long it takes to scan. Now on wallets, you really have to consider the user experience,

because if you don't, then you just don't get users. And on a mobile phone, you perhaps have, I would say, thirty seconds, twenty seconds. Maybe you have a little bit more if it's like a once off, but you know, if somebody checks their wallet once a month, once every few weeks, it needs to catch up within, I would say, twenty seconds with good progress in order to be usable. You can't do,

you know, ten minutes because nobody sits looking at their phone, keeping, you know, particularly on iOS where you have to keep it sort of alive, the app alive. No one really does does

that. Do creative things on Android where it's like in the background, it's doing the syncing so the user doesn't realize. But and also, it's not even just the user being willing to wait. If you if if it's a nontechnical user and they open up their wallet and for a half an hour it shows zero, when they really have received Bitcoin, they're gonna panic. Yep,

absolutely. And just the fact that all of that compute is going to make your phone hot, drain your battery, You know, there's just a lot of work that is really required in order to do it in this way. So for me personally, I don't think that the BIP approach is inherently

a bad approach. It's a very private approach because all the works being done on the client. I don't wanna knock the devs that are going down that path because it is a very private way. And there is a use case for that. If you're an activist, you can't run a server, you are probably prepared to sit and wait. You will make a plan. But for, you know, 95%

of people in the world, it's just not gonna work for them. So, you know, they're prepared to give up a little bit of privacy for a system that works and gets them privacy in a different way. That's what I would say. So

I decided to say, well, I don't think that this client side standing approach is the right approach. Let me try a different way of doing it. Let me see if I can move this onto a server and do it in the most performant way that I can imagine. And so the first thing I did was take all of that tweak information, all of those transactions reduced to a single key, put that in a database

and then scan that using a custom database function. And I did that because I didn't wanna have to retrieve all of that data from the database, do the compute on it and then, you know, figure out what to do next. I kind of wanted to keep the compute as close to the data as I could. So that was the reason for doing it in a database function.

Right, so I did that and I managed to bring the scanning time down from hours down to minutes, which was a huge step forward. But we were still talking about minutes and now we have a server involved, you've kind of added that on. So it wasn't really a solution at that point. It was just a step forward. It was just a step in the right direction, right? You had to kind of get down to a much better state. For example, if I had a public server, you know, I'd be able to serve one client.

That's just not gonna work. So the next step was to say, well, how can we do this thing faster? How can we do the compute faster? And I sort of looked at the whole thing and it turns out that because every transaction is kind of in terms of scanning independent from the others, it either contains a payment to you or it doesn't. You have this situation where the sort of literature on this calls it embarrassingly parallel.

I actually looked this term up today. It's a Wikipedia term because it keeps appearing in all kinds of other search searches that I'm doing, but it basically means that you can compute independently of the other computations that you're doing. And it turns out GPUs do this kind of thing really well, much better than sort of a pipeline where they have to rely on one of the other inputs in order to do the compute.

So, what I did is I basically implemented the scanning function in a GPU and I managed to bring that scan time down from minutes down to seconds, right? So we're now talking thirty seconds, that kind of thing, right? So really a big step forward and I was starting to get quite excited about this, but you know, was still

okay, but it wasn't great. The other thing that moving the compute onto a GPU did was it relieved the burden on the CPU. So if you have a server running, and then every time someone comes along and says, I wanna scan my silent payments address, and the server says, Okay, right, I'm not gonna do anything else but scan your silent payments address, you don't have a public server at that point. You just have a block which is doing only one thing.

So, you have to offload load it in order to be able to not only achieve the speed, but also just to have the server able to do normal server things. So, right. So now we have a situation where we have a GPU silent payments scanning algorithm, but what we don't have is enough speedier to really run a public server. And I think the public server is really the critical point. You know,

you think about it, I would guess most people who listen to this run their own node, but most people out there rely on the public servers in order to be able to retrieve information about their wallet. And we might say that that's not ideal, but it's just the truth of the world. And we can only take people down a path where we can make Bitcoin useful to them and then hope that they will run a node in future to increase their own privacy, but we can't force them to do it. And certainly,

you know, asking them to run a node right off the bat is just gonna ensure that they never use Bitcoin at all. So for me personally, getting silent payments to a point where we could have a public server was a critical step. It was a requirement, otherwise this technology is just not interesting at all and I shouldn't build it in. So it was important to get the next step. What was the next next step? And it turned out that the next step was improving the performance

of the GPU. And that was actually, there's a guy who came along into my, I think he posted on delving Bitcoin a month or two back and said, Hey, I've got this new project. It's called Ultrafast SCCP two fifty six ks one, which is the Curve Bitcoin Users. And his kind of focus is how can I make the fastest library that can do various kinds of cryptographic functions that Bitcoiners need? And he's just been relentless

at this. And with his help, we've managed to take the scanning time of signed payments, not just sort of 10% or 15% or 20% better, which is typically the kind of performance improvements that you can get when you do this of work. I mean, there are people out there who will spend a month getting 5% out of a particular algorithm and consider that a huge win. So, I think it's important to frame this in the right context because I was not expecting even close to the results that emerged.

And the result that emerged is we managed to get this thing 14 times faster than it was. Wow. That is just massive. Was jaw on the floor, I could not believe that it was as fast as it was. But, you know, the nice thing about silent payments scanning is that it's either right or it's not. You either find all of the transactions or you don't. And as a result, we have a system which can now do years of scanning in seconds on a public server without having to run 20 GPUs

or doing something nuts, right? We can have individuals being able to afford discrete CPUs, gaming, public servers, but that can handle thousands of clients, right? That's a huge step forward. Now, again, going back, remember the only thing that Scion Payments has going against it is scanning speed. So if we can solve scanning speed, we have a better address system. And that's the fundamental thing that if you get nothing else from this chat, that's the key point, right?

If we solve that, we have a better address system than HD Walls. Now, you know, Frigate is the implementation of this. It's not widely used yet. It's still an, I still call it an experimental service. So, you know, as many as slip to its cup and lip, and we're not there yet. But all of the building blocks, I think, are in place for this thing to replace the HD Wallet system that we all know and use today.

So how does this look in practice? Is this, I running an Electrum server and then I'm also running a Frigate server or does Frigate have all the Electrum dependencies also built into it? So, yeah, great question, Matt. So

I've kind of really just focused on the silent payments scanning part of it. And, you know, for me, I haven't wanted to build the entire kind of the Electrum server stack in. What I actually really want is for people to take the ideas or at least the code, certainly that database function, which is written in C plus or even just the idea and implemented themselves. I don't particularly need to maintain more pieces of software, but either way, we're going to have an Electrum server that

supports it. Right now, you can run Frigate alongside

something like Fulcrum and you can configure Frigate to talk to Fulcrum as a backend server and it'll just pass all of the requests that it doesn't handle itself through to Fulcrum. Fulcrum does the work or the Electrum X or whatever you use, and then it just sends it out. So you can have to clear here, Fulcrum is a Fulcrum is a highly performant Electrum server. Yes, it is. But you can use anyone, you can use it. ElectRS, you can use whatever you like. Frigate will just delegate

all of those calls that it doesn't do. You know, I may very, very well in time improve Frigate to the point where it does handle those calls. But I think the major thing to kind of understand from this chat is the solving of the silent payments kind of piece. The scanning piece is for me, I think largely at a point now where we can start to really get this out into a broader audience.

Yeah, mean, I think for professionals, right, and who I would put under professionals is like, I don't know, like Blockstream is running a public Electrum server. MZ is running a public Electrum server. These people that have been running public Electrum infrastructure for, you know, a decade now, maybe maybe a little bit less, but for years, they can easily just, know, run frigate or something similar to frigate on the side of it and and do that.

But when we're talking about, you know, home, it would like an average user using their own node and using them with silent payments. Probably the ideal setup in the future is something like, you know, one click, you're on start nine, and you install one package. And it probably, I mean, right now the current state is you install Bitcoin Core, and then you install your choice of Electrum server separately. I

guess in this situation would be, and then you would install Frigate. So you have you're installing three different packages. Ideally, I think it'd be great if there was just one, you know, but at the very least two, you know, you do Bitcoin Core, Bitcoin Nods, whatever the hell you wanna run. And then your Electrum server of choice that has, like, the frigate functionality built in. But, I mean, it's probably just

in practice, doesn't matter that much. I mean, you're just pressing install for one more thing. For the average user that's not using their node, they're installing Sparrow Wallet. They're going to sparrowwallet.com. They're installing Sparrow Wallet. They're booting up Sparrow for the first time. And it's like, okay. Are you gonna use your own node? Are you gonna use a remote node? And the way you handle it is you give them a bunch of,

like, tool tips, explanations on the privacy risks and the sovereignty risks of using a remote node that's not controlled by you. But if you choose to go down that path, because like we said, most users will not use their own node, you give them a predetermined set of high integrity nodes, nodes that have a lot of proof of work and

good reputation in the space. It's like a short list of four or five nodes for them to choose from. And the reason that is freaks for those that might not be aware is because there are a lot of malicious actors there that are running Electrum servers to track transactions. So if you're just very naive about which ones you choose and you just go with truly random, you might get stuck with a malicious one, which is why Craig, like, has a, you know, well curated list of of defaults.

I assume in a post silent payments world, those defaults will be ones that also have frigate support or something similar, have silent payment support.

For that end user, should they be thinking about the trade off pretty similar to how they think about connecting to Blockstream's Electrum server? Like, is it it's basically it's a privacy risk coupled with a risk that they might not they might not tell you if you received something that you actually received. Right? Correct, yeah. Those are the two risks, right? So you are basically running more or less the same risks. I would say, you know, it's not exactly

the same because when they scan, they obviously can say, well, you know, we didn't find any amounts to you and when there actually were amounts. So there is that risk. I think it's a pretty low But could the Electrum server say the same thing? Yeah, yeah. Well, I mean, that's it could, but you know, in practice, yeah, I have to think about that one a little bit more. There probably are some

safeguards in there. In practice, these safeguards turn out to be, you know, I wouldn't say unnecessary, but because we have many different Electrum servers, so you're gonna switch between one or the other without even really knowing it if you're connecting to a public server, you're gonna soon see if one of them has any kind of issues. It's lying to you, yeah. Yeah, so you know, in practice these kind of things don't really happen because of the way it's set up. Not that we should ever assume

that that they can't happen and we shouldn't protect against against against against them. I think that should always be considered, but they're not kind of major risks if I would say at this time. Yeah. I mean, the way you see it in practice is if you're using a wallet where it's like, pick one server, and that's it, and it doesn't rotate servers, and that server is down, let's say block streams, Internet is out, and wherever they host their server,

then you open up your wallet, and it might show a zero balance. And then some people might panic. But if and I've had people reach out to me, then you go, no, just switch Electrum servers, they switch Electrum servers, and then it shows the actual balance. And it's not them trying to be malicious. It's just they're down. But I think that kind of make I mean, I've been thinking about it a lot. I like,

it's basically it's interesting. Right? Because solemn payments has been pitched as a privacy improvement, which it net net is. So people get stuck in the perfect is the enemy of good. And so if you're using a remote server with to scan for your silent payments, you're obviously trusting that remote server with your privacy.

But as you've, I think, eloquently pointed out, silent payments actually provides improvements all across the board. So if someone is already using a public Electrum server, and now they're using a public Electrum server that is frigate compatible, or, you know, silent payments compatible, they're they're basic, they're in a privacy improved situation.

Right? Because publicly, the their their their on chain situation, what the rest of the world sees, if that server isn't logging, is significantly better than the status quo of often reusing addresses, for instance. That's correct. Yeah. I think that that puts it well. Yeah. There's

there's just a sort a net win here. If you can get around the scanning cost, know, barring a few very minor caveats, you know, which, you know, it's sort of, it's more like sharing an XPUB with that server than it is sharing a whole bunch of addresses. Know, there's minor interesting. Caveats to Because you share something called your scan key, which you can think of it as like an ID for how Oh, so it is a little bit worse than a regular Electrum server because the

way you set up with a regular Electrum server, I'm really sending them like, and that's why it solves the gap limit though. It's it's Correct. When I'm dealing with a regular Electrum server, I'm sending them like 20 addresses. I'm not sending them all 2,000 addresses I've used in a lifetime of my wallet or whatever. Yeah. Yeah. And I I think many people are gonna now say, well, you know, look at what happened to some some are some some some some summarized server when it was seized.

Right. I think the very important thing here is that electron wallets have to not store any info, right? They have to perform the computation in RAM so that if anyone arrives, the only data they have on the client is whatever they were working on at that moment in time. And you know, that's it, right? So you would have to scan the RAM in order to get that scan key out. Right. It's a similar situation that we see with VPN providers,

right? Where a VPN provider can tell you they're not keeping logs, but there's no way for you to prove if they're not keeping logs. And so some of the more reputable ones have tried to mitigate that risk more. And I know, I think Movad specifically has made a big point of keeping everything in RAM, so that if the server powers off, it auto wipes.

Correct. Yeah. And I think that that's a, you know, going back to your earlier point of don't let the best be the enemy of the good, like you can achieve so much with actually really good privacy, you know, in practice, just by saying, right, if we can keep everything in RAM, if we can use servers run by people who have a long track record of doing good things in the space, then likely we are going to have a situation where most people are fine. Like that is the likely outcome.

Now, you know, I always have to caveat it with the thing of this is Bitcoin, we running a, we're all trying to be part of a decentralized system here. If that really concerns you, run your own node. Like that's what we're all here So, to do you know, that's my strong pushback to anyone who says I don't like like that. Well, absolutely. Run your own node. You know? And the server model and it's it's

I mean, I'm famous for coming up with stacking SATs, but the lesser known is that I came up with uncle Jim, and it's been perverted a little bit. Now uncle Jim kind of also means, like, taking custody of user funds. But historically, it was meant running infrastructure that was noncustodial for friends and family. And this is where the server setup is actually really helpful, I think, is that it's not just someone,

you know, running their own node. You can also see a situation where like, maybe you're running it for your community or your meetup or something like that. And that brings that trust more local, right? If you're running it for your if you're running an Electrum server and a frigate server for your 75 meetup members. They know who you are. They can ask you questions about what your setup is, how you're doing it.

And then you're not part of a larger honeypot that maybe is serving 10,000, 20,000 Bitcoin users something like that. Yeah, so, you know, just on that point, right, if you look at the current server, which is offered by Start9, it's called the Server one and it actually has a pretty decent integrated GPU on it. I unfortunately don't have one. I'm really keen to try and get some benchmarking

on one, but I think that it would do pretty well in an uncle Jim mode. I think that it would kind of be not enough for a full public server, but it would handle just just fine a small number of users like that. Absolutely. I think you're in luck because

self hosting is kind of having its moment right now, and it's having its moment because of AI things, which are much more GPU heavy than whatever Frigate requires. So I have a feeling that if our grand utopian vision of a bunch of people self hosting and Uncle Jimming for people comes to fruition, it probably will include integrated GPUs in most of the hardware. Yeah. So we got that going for us. Yeah, for sure. I think making,

you know, as a developer, I think making a bet on GPU compute increasing in future is a pretty safe bet. And just on that note, if you're like wanting to get the most GPU compute bang for buck in like a mini PC format, the Mac Mini is the way go and it will run And why, when that's the case? It'll really do a very decent job of running Frigates. It will handle it well. Frigate

is supports a number of different back ends. So it supports CUDA. CUDA is the back end for NVIDIA chips, which are the really powerful GPUs that all of the big AI users, all of the gamers use. Those are discrete ones. It supports OpenCL, which is like an open source platform that all of the GPU providers kind of have drivers for. So that's NVIDIA, AMD, Intel, all of those guys are supported on OpenCL. And then you have Metal. Metal is the Mac OS Apple silicon back end for GPUs.

Frigate supports all three of three of those. The OpenCL is almost as fast as the CUDA, which means you, like, you don't just because you're on an AMD chip and not an NVIDIA chip doesn't mean you have really much of a performance impact at all. So there's a whole bunch of chips out there. It's almost every chip made in the last decade, not everyone, but most of them have some kind of GPU compute on them. So, you know, there's a fair chance that the

current node that you have, so long as it's not a Raspberry Pi four, has some kind of GPU compute on it. I've got this really old, like, little Intel NUC Core I five. It's running Frigate with OpenCL. Wow. Okay. The I mean, on that note, and I know we've we've talked about this at length in the past because I think you kind of from a privacy point of view, you don't love it, but you still offer it. To me, it's always been the simplest way to use Sparrow without using a public node, which is that

let's say you're running Sparrow on your MacBook, and then you're running Bitcoin Core on the MacBook too. And then Sparrow can link directly into it, basically. Is there a path here? I mean, if you support

Apple Silicon GPUs, then is there is there a situation where I in like a couple years, I can just just run Sparrow on a MacBook and not run a separate home server and it just does all the computing stuff on that one device? Absolutely. So, I mean, I'm running Frigate on my Mac right now. And,

know, as I was saying earlier, Frigate doesn't support the full set of, they make server calls now, so I'd have to run another piece of software in order to do that. But I can run Bitcoin Core, Frigate, and this, say, SelectRX on my Mac, and I have a full silent payments capable server at that point. That's awesome. I mean, that might be, I mean, if you wanna talk about actual end user support, I don't know. I mean, I remind me, can you

run Bitcoin Core in prune mode in that situation? No, right?

No, you can't because you have to scan, right? Full index, right? Yeah. So, I mean, you could in theory and I think that the Bitcoin Core silent payment support might support pruned node, but you know, it carries all of the kind of pruned node kind of things. So I have to decide whether Sparrow is going to support whether it's going to try and rely on Frigate for that sort of work or whether it's just going to fall back to the Bitcoin core scanning approach, probably the latter,

In which case, it'll just inherit whatever pruning support is inherent in Bitcoin Core's silent payment support.

Got it. And then the other piece is, you know, Lightning addresses have their own trade offs. But I think as a community or as a user base, people have really come to love the email address style usernames. Right? You know, send a payment to odellprimal dot net, for instance. Right? What's the deal with that and silent payments? I presume if you're running a server, can also just have a human readable address like that now.

Yeah. So I think that the most practical way for us to get there is probably using DNS. DNS is not perfect. DNS is ultimately a centralized system and it can and does get affected by governments. So, think that that has to be said first, but for most people, DNS is fine. It is good enough. I just would say that it's not applicable for every use case.

But with the DNS system, we have a BIP called BIP three fifty three, which is basically allows us to specify a Bitcoin silent payments address that looks a bit like userdomain.com. And effectively, that can contain a BLT12 invoice as well, which is a static invoice. So we now have a static on chain address and a static lightning address all in one kind of email address like looking Right, then I would just give them like odellprimal

dot net and the person sending me can choose if they wanna send On Chain or Lightning. Exactly. In practice. Absolutely, yeah, yeah, that's it. So it kind of is just adding that. So, you know, yeah, it's I think a really a massive step forward in terms of,

you know, having things like contact books and wallets where, you know, you can't do that today because you actually just need to go and ask for a new address every time. But now you have the idea of being able to have a sort of address book saying, wanna pay Matt. Okay. Let me go and fetch Matt's address. That kind of thing is gonna make Walletz much more usable.

And the cool part about that is that could be a separate hosted service and you're not trusting the host of your, you're not trusting the host with your privacy. You're trusting them with uptime. And can they man in the middle of that situation? For They could could serve a they could serve a fake yeah. They could serve a fake silent payment a different silent payment address. No. So yeah. So interesting point. So BIP three fifty three uses this technology called DNSSEC,

which effectively allows you to create a cryptographic proof all the way through to the root TLD, the root top level domain. And that is a requirement and must be verified by every wallet who implements this particular BIP.

So no, you actually can't do that. Again, that's not to say that governments can't interfere because ultimately the DNS system is managed by ICANN, well, it's managed by ICANN, which is in practice managed by VeriSign, which is obviously a US based corp and is under the influence of the US government. So I'm certainly not making the argument that DNS is Bitcoin's level of independence and permissionless. It's not NSA proof.

Correct, but you know, it's certainly a lot more hacker proof than you might think, so long as you have full DNSSEC proofs, which as I say, three fifty three mandates as a requirement. Wait, so can you just walk me through this? Forget about US government. Forget about the most powerful military in the world in the threat model for a second. Let's say Primal. Right? We're already hosting hosting people's lightning addresses. Right? And and navigating that comms.

Let's say we comply with BIP three fifty three, and we're hosting. And let's, you know, we're in our utopian future, we're hosting both 12 and silent payments. Why why what stops primal from like a I understand. Okay. So it's hashed and signed presumably. But how do you how do you know the source of truth? Like, how do I know that primal hasn't? I go to pay from Sparrow Wallet, and I'm going to pay odellprimal.net. How do I know that Primal isn't swapping out

the silent payment address? Yeah, so basically, you'd have to forge this proof, and that's really the hard thing to do. I'm gonna have to research the DNS spec It's above your pay grade too? Got it. Give you a better answer, Matt, because I don't wanna say something here which isn't true. It's a pretty, you know, the DNS spec is sort of a ITEF

standard. In other words, it's kind of being vetted by serious people. Got it. So presumably, I go to pay I go to pay in Sparrow, and I put in Odell at prima dot net, and it serves me a, you know, malicious silent payments address instead of the real one, then presumably something should pop up in Sparrow and be like, this is unauthenticated. It failed to check or something like that. Correct. Yeah. That's it. That's it. Don't send the payment.

That's right. It'll it'll it'll not allow you to go on. Got it. Okay. So, I mean, look, this all sounds well and good. I would love if, you know, OpenSats is 371 plus grantees were able to just give us a single fixed silent payments address. And to be clear here in that use case, you can forget about that whole DNS part we have explained. Right? They can just copy paste a something that looks like a Bitcoin address

that we can reuse over and over again. So, that whole threat model can actually go out the window. That's, I think, more for like everyday payments, and just like a UX improvement, right? How far away are we from that? What needs to be done? How can to be really

make that a reality? So, so I've got kind of a call out to three different groups in the Bitcoin ecosystem to think about this more, right? The first are the hardware wallet vendors, right? We have, as I said earlier, all of the standards in place now to implement silent payments. Now I will call out the BitBox here, they implemented a proprietary kind of implementation of sending to silent payment addresses so it's not like they've done nothing, they have done work on it, but it's not the

standards because they simply weren't around at the time. So, you know, what we need to have is adoption on a hardware wallet level because that's ultimately a very important part of the ecosystem that we just can't ignore. And if we don't have adoption on the hardware wallet level, this thing will never go anywhere. So that's the first group that I would like to appeal to, to start taking this seriously. The second group is the node vendors,

if you will. So we mentioned Start9 earlier, they've got a great platform for this. It would be great to see Frigate or even better, another implementation which uses the database extension that I use in Frigate, that would be awesome too, and integrates that. That's Can't you just package that into the community registry without permission?

I believe it can be done and I believe someone's looking at it, yeah. Awesome. But you know, I think that it needs, it might need a little bit of handholding in order to get access to the GPU, I'm not sure, but it would just be You want first class support for it on Star nine and Umbral, just like the Electrum servers are already there, right? Yeah, correct, correct. Makes sense.

Yeah. And then the third group is really the node runners. So the people out there, the individuals and organizations that you mentioned earlier, who have been running public spectrum servers for a long time to start looking at this and saying, is this something that I think I could run? What kind of hardware do I need? Because all of that stuff takes time, you have to be able to acquire it in today's world with various resource constraints. But I do believe we are now at a moment where

Frigate is not gonna get a whole lot faster. Don't think. I think we're at a point where it's fast enough, to be honest. So, you know, now is the time for it to be run, to be tested,

for us to see whether a public server can indeed be run as I believe it can. So those are the three groups that I'm really appealing to at this point to say, start looking at this thing because if we get it, if we manage to make it an upgrade path for people from HD wallets, then we have improved privacy on a very fundamental level. Awesome.

Just to be clear here, once again, just on the hardware wallet side, the Sparrow's basically right. If I'm sending a payment to a silent payment address, I'm using Sparrow to coordinate that transaction and make the PSBT. Like, it's just giving my cold card a regular Bitcoin address at that point. Right? It's not serving through the PSBT asylum payments address. It actually is. Right? Yeah. So so so basically, there are checks which the hardware wallet performs.

There's this particular element of data called a discrete log equivalence proof, a DLEQ proof. And what that does is it basically says, it allows the coordinator to check the Bitcoin address, the normal on chain Bitcoin address that the hardware wallet generates. So only the hardware wallet has enough information to actually generate

the Bitcoin address that you eventually send to derive from the silent payments address. But you can't just trust that the hardware wallet is gonna do the right thing. What if you have a compromised hardware wallet, right? You can't just have this thing which has all that power. So this DLEQ proof basically allows the coordinator to cryptographically

prove that the hardware wallet did the right thing. And that's additional fields that go into the PSPT need to be answered and filled in by the hardware wallet when it sends So we need all the hardware wallets to switch from my OpenSAT situation to come to fruition. That's That's right. Right. Are there any complications for like multisig stuff or? Yeah, there are. So multi sig and

silent payments is not a thing today. Right? In fact Well, about sending from a multi sig? So Yeah. Let's use OpenSets example again. So like open sets, our treasuries in multi sig, and then we're sending out payments to presumably, it's fine if the grant recipients are single sig. Right? I mean, I'm honestly fine with telling grant recipients, they have to run sparrow to receive their grants, they'll figure it they'll do it to get there, you know, 10,000 a month or whatever.

They'll run Sparrow to receive it. But it's a red line that the the OpenSachs Treasury has to be multi sig because we don't want a single board member being able to spend the funds. So in that situation, even in that situation it breaks? Yeah, so you can't send from multisig address to a silent payments address as of now. There are ways to do it. Can basically have an intermediate transaction, which allows you to basically send to like sort a output address.

So you kind of send two transactions in one go. So one is You're like sending to a single SIG that's programmatically Exactly. Sending to its proper destination. Absolutely. So that work has not yet been done. Still needs to be done, but there's no particular reason why that can't work. It's just one of those steps that has to be added in. Got it. So we're still bets off. Right?

I think we're now at a point where we we need people to take this thing on a broader ecosystem level. That's kind of where I'm at. And what I'm trying to do today is really just create a bit of excitement for this because there's lots of stuff all the time going on and lots of places to put your time. But as I say, I think that, you know, the building blocks are place now. There's no particular reason not to build on this. I think the most critical

issues have been solved. The standards are largely in place. We're at a point where we can upgrade and get that address reuse down. Yeah, that's my

opinion. What about in probably the, this is the the most reachable level of this usage and obviously not the final form, but it's nice because literally everything is in your control. Sparrow single sig software wallet sending to a Sparrow single sig software wallet using silent payments. That's possible today?

It's not possible today because I haven't built so I haven't had a chance to build the receiving side in, right? So, you know, that's the thing that everyone wants. And I've kind of wanted to make sure that the server side was really like solid before I did that. Because what I don't wanna do is release asylum payments wallets and then it's just a poor user experience. Was very much a you'll kill them on momentum.

Yeah, I'm actually still somewhat hesitant to do that because we don't yet have a frigate public server. Nobody's put up their hand to run that yet. But you know, I'm a little bit hesitant to I mean, you talked Wiz about it? Yeah. Yeah. I mean, I think Wiz is keen, but you know, it's it's it requires doing. We have to actually make it make it happen. Because you only really need one at first.

It'd be great to, mean, I think I don't have to tell you, but it'd be great to, at the very least, have Sparrow connect to the only public server available and then be able to test payments between another Sparrow that's doing the same. Absolutely. Then it becomes real to people. Right? That's my goal. If if

mempool. Space ran a public Frigate instance, that would be forward or at least just a public, you know, they they I have filed a feature request on the, I believe, the eSplorer repo, which is the particular flavor of Electrum server that mempool.space run. And my hope is that that feature gets built and that we we end up in a situation where we don't just have Frigate, where we have more than one Electrum server implementation,

which can use the backend work that I've done. And that's kind of ultimately the better goal. Yeah. Mean, Mempool might not be the best example because they no longer run a public Electrum server, right? It could change. So does the same provider have to run both the Electrum server and Frigate? Or could we have someone spin up a Frigate, a public Frigate node that isn't running a public Electrum server? Like, can I use Blockstream's public Electrum server and then MZ's

Fulcrum I mean, I forget server or something like that? Does that work? You could. Yeah. Yeah. I mean, look, it's it's ideal if one person does it. I mean, it's just And then it's local together. Yeah. Yeah. I think that from a performance point of view, that's kind of what you want. Otherwise, you have, you know, two hops and some transmission delay between and it's just not ideal, I would say. Got it. Okay. Awesome. I'm pretty excited about it.

Yeah. Yeah. I mean, you know, my next step is, of course, to build the receiving part in. And I think all of as I said, all of the stands are now finally there for me to be able to do it. That's the other reason that I've held off doing it to date. But I would love to launch this with a public server that can handle it. Because then I think people will really experience, you know, the convenience of it for the first time. Just how simple it is, just how

much better it is than what they're doing today. And that it'll become very apparent. And I think in a way that the words that I say here can't really express. It comes down to actually using it and saying, Oh, well, I just wanna pay and this thing looks like an email address, and I never have to worry about contacting them again to get a new address, and, you know, privacy is just handled. Like that is the experience I'm trying to work towards.

Love it. Yeah. I mean, I think in a lot of ways, like this is how people like almost assume Bitcoin should work and it just hasn't been the case. And I think it's good that, I think we need to get away a little bit from silent payments as like purely privacy tech.

I mean, even the name sounds like it's privacy tech, but it's just a UX improvement across the board for how people should be using these things. Yeah. So I mean, you know, I think we should call it SP wallets, like HD wallets, we just call it SP wallets, just makes it easier. That's what that's the kind of terminology that I'm gonna use in the Sparrow interface. Yeah, I mean, it's, I think the privacy stuff kinda comes along for the ride. It's really the convenience that's gonna make it

usable and kind of make it used, I would say. Yeah. I mean, even just the contact book piece, like you said, like, I should just have a contact book in Sparrow. And, you know, I my plumbers listen to my contact book and because I paid him once or my nanny or whatever, and I should just be able to just, like, hit the drop down, fucking pay them. Almost like a Venmo like experience or Revolut like experience.

Mean, goal and it yeah. Yeah. I mean, if if you think about it, like almost a bit one of the best

places for this technology to thrive is a place like BitKey. You know, they run the hardware wallet, they run the software wallets or the coordinator, and they run all of those kind of servers that they need, they could bring the, you know, But they don't run the Electrum server. They make a point not to run the Electrum server. They have Wizz run it. Oh, interesting. Okay. That I did not know. That was like a that was a big thing for them that they have Wizz running the Electrum server.

But, yeah, once again, they could just have Wizz run the frigate. I I mean, I think HD wallets is a really good example there, right? Because HD wallets clearly help people use Bitcoin more privately. But no one thinks of it as a privacy thing. It's just HD was like, that's, of course, of course, I'm gonna use a wallet that has a super easy backup scheme. And it's similar to the upgrade to silent payments. I think that makes sense. We have HD wallets now it's moved to SP wallets.

Yeah, absolutely.

Love it. Well, I would love to have you back on, you know, I don't know, as we get more adoption and get further along on this path and update the Freaks. Before we wrap here, do we have any final thoughts for them? Yeah. Look, my, I guess my my final thoughts apart from, you know, my particular call outs to various ecosystem players is just to keep an open mind. Many people are kind of entrenched in certain belief systems, and for whatever reason, payments may have

not been their first choice. But, you know, just look at it from the perspective of what inherent characteristics does it have and can it solve use cases for me. And that's, I guess, the way in which I've kind of come around to it. I was especially quite hesitant, certainly didn't see it as the answer at all, and it was only through a lot of time of looking at it that I kind of came around to realize

that it can indeed solve many of these issues. So, you know, that's what I would encourage people to do is just to kind of analyze it from that point of point of view. Can this be of use to me in my life? It a better way forward than what I have today? Love it. Thank you, Craig, for all the work you do for Bitcoin. My family and all my projects rely on your software, so thank you again. You're welcome. Thanks, Matt.

Frakes, I hope you enjoyed that rep as much as me. Next week, we're gonna be talking to UTXO about his new Nostrap, Wisp, which is awesome and highly performant on Android. The week after that is the Vegas conference. Don't love Vegas. I think it's kind of a it's a city I don't like going to. Let me put it that way. But I will be there, so I'm skipping that week on dispatch. I'm trying to honestly, freaks, I'm trying to reduce international travel and focus on family.

It's hard for me to avoid the largest conference in the world when there's a direct domestic flight to get there, so that's why I'm going. But we're gonna have an awesome RHR event that week. Me and Marty, we're doing it in partnership with PubKey and partnership with the Bugle Boys. You can find information for that at hotstyle.pubkey.com. Space is limited. Tickets are limited. Get your ticket now. Join us. It'd be great to meet a bunch of you in person.

And then the week after that, I'm going to have Matt Hill on from start nine. I'm talking about his new o four o upgrade, massive upgrade to start OS. So I'll be sure to bring up with him and frigate support. What he's gonna say he's gonna say that they set it up so that anyone could package these things. So I think the key is to make it clear to him that this should be a first class Matt Hill maintained package. And we'll we'll see how he takes that. Great. Sounds sounds good. Awesome.

Love you, freaks. Stay on the stack sets. Peace.