B (4:18)

Right, I'm sorry, I'm going to try and not cut you off much. But we kind of have always had it. No, 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.

A (4:32)

Yeah, no, that's, 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 unsolved 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, Matt, 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.

B (5:57)

Okay, so let's do that.

A (6:01)

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, this kind of tree. 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's 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 13 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 it, in that it does not enforce address unique fresh addresses, right? It sort of leaves it up to the user. So if you are 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 going to just send to it again. You might have 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 reused. So it's way higher than you might might think. I mean I, I don't have up to date stats. I actually have someone working on that, but.

B (8:39)

Well, it lines up.

A (8:40)

Yeah, sorry, no, it actually went as high as 50% during the 2021 Bull Run. So, you know, and that's, 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

B (9:04)

50% of people are reusing addresses, then the way bitcoin is tracked 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 going to say is it actually kind of 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 a 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 kind of go out of your way, then people tend to reuse addresses. And I'll use an example, partially why I'm so excited about silent payments is with open sats, we're sending out a multi sig 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 grant 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, make sure the right amounts are being sent, while strictly speaking, if we just had single, single address that we could send to every time, it would be, be much easier.

A (11:02)

Yeah. And you know, as, as you were saying, like just, just, you know, just because, you know, 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 going to withdraw, draw 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 is, is, was a big step forward, but it's really not getting us to where we need to be. We need to take another step, step forward. And the first attempt to move beyond that was in 2015 with the arrival of BIP 47. And I'm going to just skim over some kind of earlier attempts there because bip47 is really, I think, the first major attempt to kind of move beyond that. Now. Ber47 is still a contender today. It's still around and still being, you know, you can still use it in Sparrow, you can use it in Ashigaru, many other wallets. Bluewallet 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, the most immediate reason, is actually pretty low. It's about 1,000 sats, 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,

B (13:13)

like 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?

A (13:23)

That's right. So if you were able to track. If you were able to see. Oh, because 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 47 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 burp47 wallets, you need to have the private key of that wallet. So something as basic as just arriving 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 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 Burp 47 to date.

B (15:01)

Makes sense.

A (15:03)

So, you know, since then, we've obviously been trying to push that forward for a 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 going to 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, and they compute that data at different times in order to derive 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 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 going to make that one really tough. But on all the others we're just going to ace it. We're going to be like a green tick. On all the others, we're going to 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, 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, these different ways of being able to derive addresses.

B (17:17)

I mean, to be clear on the hardware wallet support piece, the cool part about silent payments is basically the hardware wallets are like agnostic to it. They don't 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.

A (17:43)

Yeah, so there's actually a number of different BIPs which have come out. So there's 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 bip376 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 hardware, to support silent payments on a hardware wallet level.

B (18:40)

Got it. So we, so we will need the hardware wallets to do updates, right. In order to have full support.

A (18:49)

Absolutely, yeah, yeah. So let me return now to this kind of key issue. So I just want to kind of iterate the main benefits of silent payments. Again. One, we get the static payment codes which we need, right. So 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 going to look a certain amount forward. If I don't see an address with funds in it, I'm going to 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 cannot pay the invoice, you can go on and do that 20, 30, 40 times and suddenly any new amounts 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 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, 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 light 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, and that's called a tweak. So you basically go through the entire blockchain and you say every single transaction, like 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. You 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 used 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.

B (22:48)

Is this how Cake Wallet does it?

A (22:50)

I believe so, yes. I'm not actually sure exactly what their method is, but yeah, I believe this is what.

B (22:55)

But like when you try to do with cakewild, like the scanning just takes a while. Like it's just like eventually shows up, but it's, that's the trade off. Right. It's like you're, you're basically, you have to have the app open for a while while it's scanning everything.

A (23:08)

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 going to take me around nine hours. That that figure may be a bit apart, 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 30 seconds, 20 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, few weeks, it needs to Catch up within, I would say 20 seconds with good progress. In order to be usable, you can't do, you know, 10, 10 minutes because nobody sits looking at their phone. Keeping, you know, particularly on iOS where you have to keep the, it's sort of alive. Apple, no one really does, does, does. Right.

B (24:11)

You can 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 non technical user and they open up their wallet and for a half an hour it shows zero when they really have received Bitcoin, they're going to panic.

A (24:32)

Yeah, absolutely. And just, 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 BEP approach is inherently a bad approach. It's a very private approach because all the work's being done on the client. I don't want to 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 going to 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, that's what I would say. So I decided to say, well, I don't think that this client side scanning 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 want to 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, so 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 would be able to serve one client. That's just not going to 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, the, the sort of, the 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 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, 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 30 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, it was still, it was still open, 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 want to scan my silent payments address and the server says, okay, right, I'm not going to 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, 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 speed yet to really run a public server. And I think the public server server is really the Critical point. You know, if you think, think, think about it. I would guess most people who listen, 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 going to 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, you know, there was, there's, there's, there's a guy who came along into my. I think he posted on delving Bitcoin a month or two, two back and said, hey, I've got this new project, it's called ultra fast secp256k1, which is the curve Bitcoin uses. 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 silent 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 kind 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, you know, 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. That is just massive. I was jaw on the floor, could not believe that it was as fast as it was. But 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, you know, 20 GPUs or doing something nuts.

B (31:41)

Right?

A (31:41)

We can have individuals being able to afford discrete CPUs gaming public servers with that, that can handle thousands of clients. Right? That's a huge step, step forward. Now, again, going back, remember, the only thing that silent 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, key point, right? If we, if, if we, if we solve that, we have a better address system than HD Wallets. Now, you know, Frigate is the implementation of this. It's not widely used, used yet. It's still in, I still call it an experimental server. So, you know, there's many a slip twixt cup and lip and you know, 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.

B (32:42)

So how does this look in practice? Is this, am I running an Electrum server and then I'm also running a Frigate server, or does Frigate have

A (32:51)

all

B (32:52)

the Electrum dependencies also built into it?

A (32:55)

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 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, or even just the idea, and implement it themselves. I don't particularly need to maintain more pieces of software, but, you know, either way we're going to have a 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, all of the requests that it doesn't handle itself through to Fulcrum. Fulcrum does the work or Electrum X or whatever you use, and then it just sends it out. So you can have to be clear

B (33:59)

here, Fulcrum is a. Fulcrum is a highly performant Electrum server.

A (34:04)

Yes, it is, but you can use anyone you can use. Yeah, Electrs, you can use whatever you like. Frigate will just delegate or 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 hand 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. This 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.

B (34:40)

Yeah, I 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, you know, run Frigate or something similar to Frigate on the side of it 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're installing three different packages. Ideally, I think it'd be great if there was just one, but at the very least two, you do Bitcoin core, Bitcoin knots, whatever the hell you want to run, and then your Electrum server choice that has 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 Spiral Wallet, they're going to spywallet.com, they're installing spiral Wallet, they're booting up Spiral for the first time. And it's like, okay, are you going to use your own node or are you going to 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, remote node that's not controlled by you. But if you choose to go down in 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 receive something that you actually received.

A (37:37)

Right, correct. Yeah, those, those are the two, two risks. Right. So you are basically running more or less the same risks. I would say, you know, the, it's not exactly the same because you know, 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 good.

B (37:58)

But couldn't the Electrum server say the same thing?

A (38:01)

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, 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 going to switch between one or the other without even really knowing it. If you're connecting to a public server, you're going to soon see if one of them has any kind of issues 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 them. I think that should always be considered. But they're not kind of major risks, if I would say at this time.

B (38:55)

Yeah, I mean the way you see it in practice is if you're using a wallet where it's like you pick one server and that's it and it doesn't rotate servers and that server is down. Let's say Blockstream's Internet is out 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, yeah, 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, 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 silent payments has been pitched as a privacy improvement, which 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 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.

A (40:24)

That's correct. Yeah. I think that puts it well, yeah, there's just a sort of, sort of a net win here if you can get around the scanning cost barring a few very minor caveats, you know, which you know it's sort of, it's more like sharing an X pub with that server than it is sharing a whole bunch of addresses. You know there's minor caveats to that.

B (40:48)

Yeah.

A (40:48)

Because you share something called your scan key which you can think of it as like an ID for.

B (40:53)

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. But it's, it's when I'm dealing with a regular like from server I'm sending them like 20 addresses. I'm not sending them all 2000 addresses I've used in a lifetime of my wallet or whatever.

A (41:13)

Yeah, yeah. And I think many people are going to now say well you know, look at what happened to some, some, some, some of some, some, some, some, some summarized server when it was seized. Right. I think the very important thing here is that electro 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.

B (41:50)

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 try to mitigate that risk more. And I know, I think Mulvad specifically has made a big point of keeping everything in RAM so that if the server powers off, it auto wipes.

A (42:16)

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 I always have to caveat it with the thing of this is Bitcoin, we're all trying to be part of a decentralized centralized system here. If that really concerns you, run your own node, like that's what we're all here to do anyway. So 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

B (43:10)

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 non custodial 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, a larger honey pot that Maybe is serving 10,000, 20,000 Bitcoin users or something like that.

A (44:18)

Yeah. So you know, just on that point. Right. If you look at the current server which is offered by start start9, it's called the server1 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. 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. Absolutely.

B (44:51)

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. So we got that going for us.

A (45:19)

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 like wanting to get the most GPU compute bang for buck in like a mini PC format, the Mac mini is the way, the way to go and it will run.

B (45:38)

That's why that's the case.

A (45:41)

It'll really do a very decent job of running Frigates. It will handle it well. Frigate supports a number of different backends, so it supports cuda. CUDA is the backend 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 macOS, Apple Silicon backend 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 as Long as it's not a Raspberry PI 4 has some kind of GPU computer on it. I've got this really old like little intel NUC Core i5. It's running frigate with OpenCL.

B (47:01)

Wow. Okay. I mean, on that note, and I know 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 has 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?

A (47:53)

Absolutely. So I mean, I'm running Frigate on my Mac right now. And you know, as I was saying earlier, Frigate doesn't support the full set of 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 Electrs on my Mac and I have a full silent payments capable server at that point.

B (48:20)

That's awesome. I mean that might be, I mean, if you want to talk about actual end user support, I don't know. I mean, remind me, can, can you run Bitcoin Core and prune mode in that sit? No. Right?

A (48:36)

No, you can't because you have to scan.

B (48:38)

Right. Full index. Right?

A (48:39)

Yeah. Yeah. So I mean you could in theory and I, I think that the Bitcoin Core silent payment support might support Prune Node, but you know, it carries all of the kind of Prune node kind of thing. 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. The scanning approach. Probably the latter, in which case it'll just inherit whatever pruning support is inherent in Bitcoin Core's silent payment support.

B (49:11)

Got it. 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 odell@primal.net for instance. Right. What's the deal with that in silent payments? I presume if you're running a server you can also just have a human readable address like that now.

A (49:39)

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 I think that that has to be said first. But for most people DNS is fine. It is good enough. It just would say that it's not applicable for every use use case. But with the DNS system we have a BIP called BIP353 which is basically allows us to specify a bitcoin silent payments address that looks a bit like useromain.com and effectively that can contain a belt 12 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 location.

B (50:40)

Right. Then I would just give them like odell@primal.net and the person sending me can choose if they want to send on chain or lightning.

A (50:48)

Exactly.

B (50:48)

In practice, absolutely.

A (50:50)

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 that now you have the idea of being able to have a sort of address book saying I want to pay Matt. Okay, let me go and fix Matt's address. That kind of thing is going to make wallets much more usable.

B (51:20)

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 in that situation. They could serve a fake. Yeah, they could serve a fake silent payment, a different silent payment address.

A (51:46)

No. So yeah, so interesting point. So BIP353 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, the DNS system is Managed by icat. Well, is managed by. You know, it's managed by icann, which is in practice managed by Barry Sign, 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 permissionlessness.

B (52:37)

It's not NSA proof.

A (52:39)

Correct. But, you know, it's. It's certainly a lot more hacker proof than you might think, so long as you have full DNSSEC proofs, which, As I say, 353 mandates as a requirement.

B (52:52)

Wait, so. But let's just walk. 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 bip3.53 and we're hosting. And let's, you know, we're in our utopian Future. We're hosting Bolt 12 and silent payments. Why? Why? What stops Primal from, like. I understand. Okay, so it's hashed and signed, presumably. But how do. 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 odell@primal.net. how do I know that Primal isn't swapping out the silent payment address?

A (53:48)

Yeah, so basically you'd have to forge this proof, and that's really the hard thing to do. I'm going to have to research the DNS specifically, give you a better answer, Matt, because I don't want to 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.

B (54:12)

Got it. So presumably I go to pay. I go to pay in Sparrow and I put in Odell@primal.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.

A (54:31)

Or something like that. Correct. Yeah, that's it. That's it.

B (54:35)

Don't send the payment.

A (54:36)

That's right. It will not allow you to go on.

B (54:40)

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've explained, right? They can just copy paste 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 and how can people be helpful to make that a reality?

A (55:19)

So, yeah, 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've got to call out the bitbox here. They implemented a proprietary kind of implementation of sending to silent payment addresses. So they, it's not like they've done nothing. They have done work, 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, the node vendors, if you will. So we mentioned Start nine 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. So that.

B (56:38)

Can't you just package that into the community registry without permission?

A (56:43)

I believe it can be done and I believe someone's looking at it. Yeah, but 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.

B (56:59)

You want first class support for it on Start nine and Umbrella, just like the Electrum servers are already there, right?

A (57:04)

Yeah, correct. Correct.

B (57:06)

Makes sense.

A (57:07)

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 Electrum 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 and in today's world, with various resource constraints. But I do believe we are now at a moment where frigate is not going to get a whole lot faster, I don't think. I think we are 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.

B (58:13)

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, right?

A (58:42)

Yeah. 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, the, the bitcoin address, the normal on chain bitcoin address that the hardware wallet generates. So only the hardware wallet has the 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's going to do the right thing. What if you have a compromise 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 and need to be answered and filled in by the hardware wallet when it sends.

B (59:46)

So we need all the hardware wallets to switch from my open SAT situation to come to fruition.

A (59:54)

That's right, that's right.

B (59:55)

Are there any complications for like multisig stuff or.

A (59:59)

Yeah, there are. So multisig and silent payments is not a thing today, right?

B (60:06)

In fact, well, what about sending from a multisig? So let's use OpenSets example again. So like opensats, our treasury is in multisig and then we're sending out payments to. Presumably it's fine if the grant recipients are single sigma, 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 their $10,000 a month or whatever, they'll run Sparrow to receive it. But it's a red line that the open satch treasury has to be multi sig because we don't want a single board member being able to spend the funds. So even in that situation it breaks.

A (60:46)

Yeah. So you can't send from multisig address to asylum payments address as of now. There are ways to do. You can basically have an intermediate transaction which allows you to basically send to like, like sort of sort of a output address. So you kind of send two transactions in one go.

B (61:07)

So why sending to a single sig that's programmed programmatically sending to its proper destination.

A (61:14)

Absolutely. So that, that work has not yet been done. That still needs to be done, but there's no particular reason why that can't, can't work. It's just one of those steps that has to be added in.

B (61:26)

Got it. So we're still bets off, right?

A (61:32)

I think we're now at a point where we, we need people to take this thing on on a broader ecosystem level. That's, 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 in 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 reused down. Yeah, that's mine.

B (62:13)

What about in probably the. This is 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.

A (62:37)

It's not possible today because I haven't built. I haven't had a chance to build 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 want to do is release asylum payments wallets and then it's just a poor user experience. That was very much. 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.

B (63:12)

I mean, talk to Wiz about it.

A (63:14)

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.

B (63:20)

Because you only really need one at first. Right. It'd be great to. I mean, I. I think I don't have to tell you, but it'd be great to at the very least, like, have Sparrow connect to the only public server available and then be able to test payments between another Sparrow that's doing the same.

A (63:42)

Absolutely.

B (63:43)

Then it becomes real to people.

A (63:44)

Right. That's my goal. If. If Mempool Space ran a public Frigate instance, that would be. Or at least just a public. You know, I have filed a feature request on the. I believe it, the Esplora 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.

B (64:24)

I mean, Mempool might not be the best example because they no longer run a public Electrum server.

A (64:28)

Right. It could change.

B (64:31)

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?

A (64:50)

You could. Yeah. Yeah. I mean, look, it's. It's ideal if one person does it. I mean, it's just.

B (64:56)

And that is local together. Yeah.

A (64:57)

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. It's just not ideal, I would say.

B (65:11)

Got it.

A (65:13)

Okay.

B (65:14)

Awesome. I'm pretty excited about it.

A (65:17)

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 standards 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, 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 want to 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.

B (66:10)

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. Right. 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.

A (66:33)

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 going to use in the Sparrow interface. Yeah, I mean, it's, it's, it's. I think the privacy stuff kind of comes along for the ride. It's really the convenience that's going to make it usable and kind of make it used. I, I would say, yeah.

B (66:58)

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, 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, pay them. Almost like a Venmo like experience or a Revolut like experience.

A (67:19)

Yeah. Yeah. I mean, if you think about it like almost the. 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 wallet or the coordinator and they run all of the kind of servers that they need. They could bring the, you know, it's.

B (67:42)

Well, they don't run the Electrum server. They make a point not to run the Electrum server. They have Wiz run it.

A (67:46)

Oh, interesting. Okay. That.

B (67:48)

I did not know that was like it was a big thing. For them that they have Wiz running the Electrum server. But yeah, once again they could just have Wiz run the frigate. I mean, I think HD Wallets is a really good example there.

A (68:02)

Right.

B (68:02)

Because HD Wallets clearly help people use Bitcoin more privately. But no one thinks of it as a privacy thing. It's just hd like that's. Of course, of course I'm going to 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 let's move to SP wallets.

A (68:28)

Yep. Absolutely.

B (68:31)

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, we have any final thoughts for them?

A (68:46)

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. You know, many people are kind of entrenched in certain belief systems, you know, 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 initially 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? Is it, is it a better way forward than what I have today?

B (69:50)

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.

A (70:01)

You're welcome. Thanks, Matt.

B (70:03)

Freaks, I hope you enjoyed that rep as much as me. Next week we're going to be talking to UTXO about his new Nostr app, 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 going to have an awesome RHR event that week. Me and Marty were doing it in partnership with Pub Key and partnership with the Bugle Boys. You can find information for that@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 040 upgrade, massive upgrade to start OS. So I'll be sure to bring up with him and frigate support what he's going to say. He's going to 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.

A (71:31)

Great. Sounds. Sounds good.

B (71:34)

Awesome. Love you. Freaks. Stumblestack sats pace.