Silent Payments: A Bitcoin username?

Hi everyone, welcome back to Stephan Livera podcast brought to you by Swon dot com, the best place to buy Bitcoin. Joining me today to talk about silent payments are Josibake and also Ruben Somsen. So welcome back to the show, Josie and Ruben, first time. Yep.

Hi. I think, I think it's the second time for me, and as I was pulling out the microphone and setting up in the kitchen, I was like, "I think the last time I touched this microphone was two years ago when I talked with, You, you about education, I think.

Yeah, I think I remember that episode. We'll, we'll, we'll link that in the show notes for people who wanna go, who wanna go back and revisit that one. and so, yeah, let's talk a little bit about silent payments. There's been a bit more noise about this. Obviously, there's been a bit of conversation about, you know, Bitcoin needs more privacy on chain, and so I guess that's driving some of this. so maybe Josie, do you wanna just give us like a, just a kind

Yeah, so Silent Payments is BIP352 and it's a proposal for reusable addresses in Bitcoin. so something that you can post publicly to like accept donations that I could give to you, you know, if you're like, I'm getting paid in Bitcoin and I, I need, you know, twelve payments over the course of the year, I just give you that one address and you can reuse it to send me stuff. and, you know, we talk a lot about on-chain privacy, but this is even more just like a step above on-chain, I would say, where nothing on-chain is really changing with silent payments, but we're more getting some better usability and privacy in that layer of how do I communicate to you how I wanna be paid? and as we know with traditional Bitcoin addresses, we're not supposed to reuse them, and we're also not supposed to even post them publicly, 'cause as soon as you post, you know, a Taproot address or a SegWit address somewhere, anyone Explore. So Silent Payments is trying to address that area right there of how do we communicate the instructions of how we wanna be paid in a private way and also a way that, I, I would say has good user experience.

Yeah, so, one thing I would add to that is, essentially, I mean, it's almost the same as what Josie said, but like it really is that we currently sort of have this, two, two bad choices. We have the choice of either you have to interactively every time you wanna send a payment, you have to receive Or, you have to reuse your address, and then everybody can see how much money you received. And I would say that this is basically-- it makes Bitcoin work like the average newbie would think it works, which is just like a bank account, where you have a bank account number, and people can send money to it, and then that would be sufficient, for you to receive money in a way that nobody else knows how much money you received. but in Bitcoin, it doesn't work like that. You need to create a new address every time, and now that Still, maintain privacy with, with silent payments. And so it, it simplifies the UX, in a way that, still maintains, privacy essentially.

Gotcha. Yeah, that's a good point to make for people, for listeners who are maybe not as into the detail. Let's get into a little bit of the history of this idea. I think Ruben, you'll probably be best placed to explain a little bit. There are other ideas out there, I know a lot of people might be familiar with, or they might have heard of Bit 47, and they might have used, let's say, Samurai Wallet or Sparrow Wallet with Paymims. How does this idea sort of compare with other ideas out

there? Yeah, so it, the stealth address idea, which is basically there, there's a very like old cryptographic trick, which basically allows, two people have a key to generate a shared secret, so it's something that only the two of them know. and you can use this to, to essentially generate, what you could consider a two of two multisig address, where one of the keys is known by the sender and the recipient, and the second key is known only by the recipient. And so effectively, it just means it, it becomes, re- recipient key, because, the, the recipient knows both of the keys. and so this, this stealth address trick, has been known for a long time, has been discussed for a long time, like I think back in twenty twelve already, like people were saying, like, "Oh, yeah, we could use this for Bitcoin." But it never really quite came together in a way that was fully elegant. and, so the, the, I think Peter Tann's stealth address proposal, essentially required you to put another key on chain in either up return or something, and so that would do two things, like, like one, it would make it so that it was very obvious that you were making a stealth address payment because it had this up return data, and so, you, you would be able to distinguish it from e- Any non-stealth address payments, and so that's bad for anonymity, and it's just on-chain inefficient, right? So you have to add extra data, so it's more costly to make a payment like that. then the, sort of second idea that, that really was, I think, already thought of back then was like, hey, why don't we use one of the keys that are already in the transaction, and do it that way? but that never really gained any ground, basically for a couple of reasons, I would say one, at the time it was seen to be, just a little bit too, complicated. also, we didn't have, have, Lipsec P, This, basically the library that now, does all the, cryptography, and, yeah, that, that's at, at like six, seven x, improvements over like how fast, these opera-- like doing these calculations used to be, so it was sort of considered like, too expensive of an operation, to, to add to Bitcoin. and so the idea sort of died down and nobody really did anything with it. then came along BIP, forty-seven, which basically said like, okay, look, A little bit, we add some data to the blockchain, but we're not gonna do it with every, every time you make a payment. and so instead, what Bip forty-seven chooses to do is say, like, okay, we're gonna create a notification, we're gonna send some, we're gonna put some data on chain once. and that data, will be recognized by the recipients, and then the recipient will basically know what secret to pay attention to, and then in the future, you're gonna use that secret to make repeated payments And so, the-- this, the nice thing about this is that it's very clear, to the recipients what they have to do. they don't have to check everything on chain, they just see a message that belongs to them, and then they're like, "Okay, I'll pay attention to that." the downside I would say is, a couple of things. for one, the UX on the sender side is quite, difficult because now you have to-- before you make a payment to someone, you first have to make a notification, to them, and that's another on-chain transaction, and I think especially if fees start to go higher, that'll be a little awkward, but also UX-wise, it's just a little, difficult. it's more, on-chain data, which is, you know, To essentially what you're doing is you're, you're notifying one specific person about something that isn't directly about a payment, so it's sort of like, okay, well, that, that seems like a wasteful use of block space and another big thing is that it's, it links the payments, you, you sh- you reveal to the recipient when you're making repeated payments as a sender. So if I were to use Bit 47, I would pay you multiple times then you would, well, you'd see two things. the, the, the, the, the main thing you would see is, okay, somebody paid you, multiple times, whereas with silent payments, you wouldn't, you wouldn't be able to recognize that it's the same person paying you multiple times. and, the other thing is that with BIP 47, although this, this would be solvable if you use another, BIP, with BIP 47, I, in the, in the notification transaction, I actually reveal my, my payment code, my BIP 47 payment code. So I'm actually revealing my, identity as well to the recipients, which It's not, not great. Like, if you, if you didn't want that to happen, then, yeah, now you're, you don't necessarily want to, to have the recipient know who you are as the sender, especially let's say you're donating to a cause and, it's somewhat controversial, and now they have data about you, that, you know, could leak, you wouldn't necessarily want that. So I would say those are sort of the differences. and of course, like, I, I think, you know, this is already like a little bit going to the weeds because, you know, we're making these comparisons and we're, we're talking about technical things. but the, the, the one downside that Silent Payments have over BIP forty-seven is that there's a scanning requirement. So you have to, essentially pay attention to the blockchain, do some extra calculations, and figure out, whether or not you got paid. If you run a full node already, the cost of that is essentially

Make it, pretty viable. so I think, yeah, that's, that's probably we'll, we'll be discussing that, yeah, further on. Okay, so let me just list out

a few of the things there, so just to, 'cause there was a lot there, so just to make sure everyone's following along. So, they're in the BIP 47 style that's widely adopted. There's a notification transaction, as you said, the recipient knows if the sender is doing multiple payments, which maybe they don't want that, and the recipient can connect those payments back to, you know, a particular individual in certain cases or a particular identity, to be clear, and there's also an argument around worse on-chain efficiency. Now, the downside, as well, as you mentioned, to be fair, is the computational- Expensiveness, right? It's, it's more computationally expensive, and so maybe that might-- would that make it more difficult to sort of run, let's say, like a public Electrum server or something like this kind of infrastructure if lots of those people want to also use silent payments?

Yeah, I think I'll just-- before I answer the Electrum question, I think one thing that's been really interesting to me in how I think of like the narrative arc from like the earliest address to where we are now. you have this thing of bandwidth and computation. And in the early days of Bitcoin, computation was the most precious resource. Like even calculating a signature, verifying a signature was an expensive operation, doing elliptic curve operations were expensive. and on-chain was basically free, right? People were relaying zero fee transactions, people were worried about people filling up the blockchain because there wasn't enough demand for it. And so for all intents and purposes, like on-chain was not really that scarce of a resource. Source. And it's interesting when you look at in that framework, because you see the original proposal with, stealth addresses, they were like, "Let's just put an ephemeral encrypted key into every single transaction in an op return, because on-chain is free. We're gonna use op returns for all kinds of stuff." And then later on, you had Bit 47 and, other proposals, which I'll just call the notification style proposals, and they're like, "Okay, well, no, we really can't put an op return in every single transaction, 'cause So it's like, okay, we'll, we'll establish a payment channel. So we go from a piece of data in every single transaction to a piece of data per counterparty, right? So Bitforty-seven and other notification style ones, you, you establish a payment channel with every person that you're gonna expect to have repeat payments. So we've gone from data in every transaction to data per every counterparty But on-chain has continued to become more expensive and more scarce of a resource to the point where I see silent payments as the next evolution of that. It's like, what if we could get rid of that completely? Now we don't even need the on-chain space per counterparty, and we can just make it just the transaction itself. Now, at the same time, every time we've made this trade off of space, we've necessarily got to do some more computation. It was the same with, you know, stealth addresses to Bit 47. With Bit 47, there's some more computation they're doing on the client. and with Silent Payments, I think we're just continuing to follow in that, where there is more computation on the Silent Payments side, but what we're getting rid of is all of the, on-chain space requirement. And if we keep thinking about the trajectory of where Bitcoin's gonna go On-chain space is gonna continue to get more and more expensive, whereas computation is going to get better and better and better, and we've already seen that with like Ruben mentioned Libsack P, but even just CPUs and processors on phones and, and everything like that, we're getting to this point now where If I can design a very simple protocol and just throw compute at it, that's gonna be far better than coming up with all these tricks and more complexity to avoid just spending the CPU power, because the CPU power is more abundant, the space and the complexity and all these other trade-offs that kind of the earlier protocols were making, I think we're outgrowing those approaches. I think they were great at the time, and, you know, Bit 47 made a lot of sense, even stealth addresses made a lot of sense back when like compute was very expensive. And Bitcoin block space was basically free, but as we've kind of moved into this era now where that's flipping, I, I don't even really see these as competing proposals anymore. I just see it as the evolution of like, as on-chain space gets more and more expensive, we're naturally gonna have to migrate to things that are far more space efficient And potentially make that sacrifice by just throwing a whole lot of compute at the problem.

Yeah, really good points. And so I would summarize, I think the other, as, as we're kind of broadly talking about it, obviously we've mentioned these, but the kind of big wins I see are this idea that you can have a static QR, but it's actually not reusing addresses, and it kind of, as you were saying, Josie, I think in some online discussions, it's like we, we can kind of bring this idea of a Bitcoin username, and it's not exactly that So then, whenever people are doing on-chain payments, now it's like, it's a much simpler UX instead of me going to ask Ruben or ask Josie, "Hey, give me your address and let me pay you." Now it's more like, "Oh, I, you know, it's kind of like having a contact list and a contact, that you can just reuse." And so that's really, useful. So, do you wanna just touch on where things are at right now with silent payments in terms of wallet support and just to kind of explain, this This is something that's happening at the wallet, you know, in wallets.

Yeah, it's-- So I, I can speak to that 'cause that's where I've been the most active. so, you know, to your point about a consensus change, this is just a, a wallet protocol, right? Like it's something that, it's, it's a protocol for different wallets to- Communicate with each other, doesn't, I w- you know, we could say application layer, right? We're not talking about anything in Bitcoin's consensus here, which is kind of nice, right? I, I always get excited when there are these opportunities to improve the, the, the usability and the privacy of Bitcoin without needing to get the entire Bitcoin community to agree with you. and so this has been kind of a fun one, I think. So in terms of status, we've been-- you know, Ruben proposed the original idea back in like March 202 2022 got involved, and then, you know, we sat down and like, "Okay, let's write a BIP, let's start working on implementations." the BIP was just recently merged. I would say it's been Ready-ish for like six months, maybe four months, with like minor tweaks, but it's, it's merged in the bit repo right now. And so, you know, having a bit merged just means like we're considering the spec final enough to start building on. you know, maybe as people start building, we're gonna notice oversights or little things that need to be tweaked and fixed, whatever. But having the bit been kind of like the, the, the merged, like ready-to-go status is a signal to wallet developers, hey, this is ready to build. Like you guys You guys can start building this and using this. so we've, we've got that, the BIPs got, test vectors that, that wallets can use for implementing it, et cetera. So Even before the BIP was merged, I was working on an implementation for Bitcoin Core, 'cause that's the codebase I'm most familiar with, that's the wallet that I use. and it's also, you know, with the Bitcoin Core approach, we're-- I've got PRs open for send and receive support for Bitcoin Core, but we're also looking at building a, a, a light client index, so an index in Bitcoin Core that could serve you know, like Electrum server or something like that. So that work's been going on for a while. And then more recently, myself and another contributor, we started a, a module for Libsecp, which Ruben mentioned earlier. It's the cryptography library that we use in Bitcoin. And so we started writing the module, for Libsecp because the idea there is it's gonna be as efficient as possible. And with silent payments scanning, we've mentioned the computational overhead, so we wanna make sure that there's an option out there that just nails it, and like As efficient as it can be. So we've been working on that. And also with, with cryptography, you, you don't want people out there rolling their own crypto. And silent payments is this tricky one where, yeah, it is just like application layer wallet stuff, but it's also got some cryptography in there where we're doing elliptic curve Diffie-Hellman, we're doing some key tweaking, and we don't really want to just be like Good luck everybody. so the idea with the Libsecp module is we can give this very high level safe to use API, for wallet implementations where they don't even really need to know the cryptography underneath and they can just use these high level function calls to do it. So that's what, what I've been working on. there was another group that, started working on like a Rust Silent Payments library that I was chatting with, and then they've been working on a light client called Donation Wallet that uses Bip 158 and Silent Payments. I think that's on Cygnet right now and testing. and then KWallet, kind of came out of nowhere, and one of their developers reached out and was really excited. And for KWallet, I think it just clicked for them because their users are primarily you know, they're, they're a multi coin wallet, but I think they kind of target Monero and Bitcoin. They have a, a version of Cake that only has Monero and Bitcoin, and they're kind of more plugged into what those communities are doing. So they're like, "Oh, this is great. This is the user experience that our Monero users want. They already have like the Monero, I forget what the name they use, but they're basically stealth addresses." And what's funny about the Monero users, their light clients already have to sync. They have to download the way that the stealth addresses work in a Monero, they, they have to download the blocks and scan. So they were like, "I don't know why everyone's complaining, this isn't gonna work for light clients, this is how it works in Monero, and it seems like yours might, might work even better, so this is super exciting." And they kinda ran with it, I, and I was chatting with them, so they have a beta, a, a public beta right now that's usable, that's what I've been using, I think it's pretty awesome, I've been pretty happy with it. And then you, you mentioned, or maybe one of, you mentioned Silentium, there was like another one that kind of popped up. as a progressive web app that was also connected to like an, an indexing service. the progressive web app was pretty cool, but I, I don't think it's performing enough. I, I was playing around with it and testing it, and, you know, just kind of further convinced me of the need for the Libsack P module because they were doing the cryptography part in, TypeScript, and it just, it just wasn't fast enough. so very quickly, you know, you could play with the wallet, but then if, if you went a couple days without scanning, it kind of felt like it was struggling to catch up. but then there's been a few others out there as well that have been playing with the idea and, It interestingly enough, everybody kinda is focused on light clients right now, which is funny to me because, you know, it's kind of a no-brainer if you're a desktop wallet or a full node. but on the implementation side, I'll, I'll mention this as well 'cause I think this is really important, and this is kind of a call to action for everyone out there. One of the things we tried to take into account with silent payments is that Whenever you're introducing a new address format or a new protocol, what you really want is broad sending support. So using Taproot as an analogy here, Taproot goes out and exchanges won't implement Taproot support, and rightly so because there's no wallets that can use it. So, you know, an exchange says, "Hey, we, we support, you know, receiving to a Taproot address," and it's like, "Yeah, but like, none of the wallets in the ecosystem can even parse a Taproot address, so what's the point?" So we wanted to try to get ahead of that and be like, right, when we design silent payments, let's separate the sending and receiving. So you can implement just sending without needing to implement receiving, and let's try to make the sending as easy as possible compared to receiving. so that would be my call to action to people out there, and I think BlueWallet has kind of- Started looking into, implementing sending support, because if we have a lot of wallets that are doing sending support, that's a signal to other wallets that, it might be worth me to do the engineering to, enable receiving support. And also any wallet that does have receiving support immediately becomes more useful, because there's lots of people that can, can send to that wallet. the, you know, the nice thing too about sending, everything we've talked about with trade-offs, you know, computation, more bandwidth for light clients, none of that applies to the sending side. There There's, there's, I mean, you, you basically have to parse a new batch thirty-two-M encoded address, like a, like a Taproot address, and you need to do some of the cryptography side to, to send the transaction. But, you know, whenever we talk about trade-offs and other things like that, I wanna make sure that's clear that we're talking about the receiving side.

Gotcha. Okay, great. And so when, if you could just kind of walk through, like, just at a very simple level, what does it look like for the user, right

And it's already connected with your own full node. What would it look like? Like you generate a, a, an SP code and that can represent as a QR and that's what you show people and anyone can just-- anyone who has silent payment sending support can scan that or copy-paste the code and that's it. That's the, that's the rough- Flow, right? That's what it looks like.

I mean, that, that's, yeah, that's pretty much it. I mean, I, I would say even hopefully it's a little easier, you know, if we, if we think of like a Taproot address, it has that B C human-readable part which indicates it's a Bitcoin address, then we have the separator one, then we have the letter P which indicates the version, and then the rest is batch 32 M encoded. Silent Payments follows the exact same thing, where we use batch thirty-two M encoding, which is the one that, Taproot addresses use. Instead of BC, we have a new HRP, which is SP, and this indicates, you know, this isn't a traditional Bitcoin address, it's a Silent Payments address. We have the separator one, then we have a version, the, you know, we're on version zero of Silent Payment addresses, which is the Q, and then you'll see a long string of batch thirty-two M encoding. What's in that, tying it back to That you decode is a public key. In silent payments, we have two public keys, and those two public keys don't represent a script pub key that you're gonna send some Bitcoin to, like they do in a traditional address. They represent instructions on how to create a Taproot script pub key. So basically, you read the ad, you know, you're, you're, you wanna receive, you just generate this address. It looks like a, a longer Bitcoin address. You post a QR code somewhere. My wallet supports sending, scans that, reads it. Recognizes the SP, oh, this is a silent payment address, gets the two public keys from the address, and then uses those public keys and the Diffie-Hellman cryptography that we've talked about To create a script pub, a Taproot script pub key for you, the recipient, that then goes into the transaction. But from like a user experience level, it's really just, I see something that doesn't sound like payment address, I scan, I send to it. And for me as a receiver, you know, the flow on like, like Cake right now, you pull it up and you go to the receive page and they have an option there of silent payment address and you pick that one, and then you could keep reusing it or give it to someone. with it being safe to reuse.

Yeah, I mean, the, the flow is no different from just having a single Bitcoin address and reusing it all the time, but not losing your privacy. That's, that's essentially what it's gonna be like.

Yeah, and so this would be, I mean, this is important too, like from the sender side, one very different thing in the flow now compared to Bit 47 and Bit 351 and, you know, everything else is I see a silent payment address, I send to the silent payment address, we're done, one transaction. Whereas in any of these other proposals, it's usually, I see a payment code, I make some sort of initial notification, which can either be transmitted out of band, but then I need to make sure that the recipient has it, or they're not gonna be able to find my subsequent

payment. That's not an option essentially.

Yeah, I mean, yeah, but like, more just The arguments that people have used, in practice, it means you need to make an on-chain transaction. So I wanna, you know, Stefan, I noticed you post your new, your, your new code. If you're not using silent payments, that means like when I pay it, I gotta pay for a full on-chain transaction, pay the fees, wait for confirmation, then once it's done, then I can send you a payment that you would actually find. So I think from the sender side, we're talking about a pretty huge step up in the user experience, and then we Recipient, where now the recipient has to do the scanning.

Yeah, and, and hopefully that will also help adoption, right? Because like, you know, I, I said it in the beginning, but I, I really think the sender side UX needs to be as simple as possible, because that's what you need for adoption. You need everybody to implement a sending support. And then for receiving, as long as there's one good wallet out there, you know, everybody who wants to receive silent payments can just start using that wallet and then receive their silent pa-payments on there. But you want

I think, literally, sending support relatively easy and, the thing that we need to spur on adoption. So I think adoption hopefully is gonna be sort of similar to how Taproot addresses are, you know, in use now and, supported by a lot of wallets. Not, not all wallets, obviously, but, that's, that's what I'd say.

Yeah. Okay. And now let's talk a little bit, you touched on this before around light client support. What does that

look like? Yeah. Yeah, so that I went to because earlier on you also asked about Electrum, and, I, I think one of the things to sort of realize, and, and the thing that we realized as we were working on the BEP was that a lot of wallets Take shortcuts to make the user experience better, like light wallets. and those shortcuts generally don't favor privacy, right? So, you end up with, and, and we've seen this also with a lot of Bit 47 wallets, where, you, you end up querying a server about your addresses, and then that server learns everything about the stuff that you're trying to keep, keep private in the first place. So your, your, your threat model, okay, so you're, you're not, you know, on-chain, you're stuff, but to a single server that you're connecting to, you, you're still, leaking all your privacy. and so the obvious model, and I think the one that always works, and that includes silent payments too, is just connect to your own full node, right? Run your own election personal server, have, have that do everything that you, you require, and that, and that just functions. And for silent payments, that would be, no problem either, and that would work really well. but the tricky thing is how do you do it without running your own full node? and that is, I think, the part where either you make privacy shortcuts or you gotta have a wallet that does a lot of things right, and, and that includes something like silent payments, but also, implementing Bit One Fifty Eight, so, you don't have, you don't have to, so with Bit One Fifty Eight specifically

Have an address that you're interested in, you can basically check a filter to see, hey, is this, is this, a transaction that might, might be in a blo-in this block? And then you sort of get an answer that is probably or, or, or definitely not. And if the answer's probably, then you download the block and you check. And so what ends up happening is that instead of you leaking, hey, I wanted to know information about this specific transaction, you only leak, hey, I'm downloading a specific block and it may or may not contain transaction I'm interested in. So it sort of gives you a good anonymity set. and the, the big downside, and the reason why a lot of wallets haven't implemented this is because it ends up, requiring, down-- downloading more, more data, doing more, more work on your phone. and that, that is a slight hassle for the UX, because now, the wallet has to, you know, maybe tell the user to wait a little bit or, or have the user press a button and say like, " Check the last, last couple of blocks now, or, or, do it when you're connected to Wi-Fi or something like that. And so if you wanna be really bandwidth preserving, then, losing privacy is a good option. But if you wanna maintain your privacy and you will still, you're, you're willing to sacrifice a little bit of user experience, right? Like it's not gonna be like one hundred percent smooth, but, but it will be pretty good still. then you need something like Bitcoin fifty-eight. And silent payments slot in there really well, a-and we have essentially, a proposal or a, a, a, a design, for, allowing people to do, their scanning, so checking whether or not they received a transaction, by essentially receiving, a bit of metadata about every block. and the metadata is essentially for every transaction, someone who, who, runs a- A server and is willing to, to create an index for silent payments, will generally, will basically take every transaction, generate a, a thirty-two byte number, and give you those thirty-two byte numbers, if you're a light client, and then you can use those to generate, essentially what are, outputs that you think might be a payment to you, and that is what you check the filter with. and so like long story short, essentially, you download a little bit of extra data, with it Extra data, you can do all the scanning yourself, and you still aren't a, a full node, and that is sort of, what we've achieved here. And, and, and one nice thing about this is that we have, support for cut-through. so essentially, if a transaction has been fully spent, then you know it can't be a payment to you, or, rather, it's, it's not money that you currently own, at the very least. so we also have a sort of a mode where you skip those

Yeah, I'd-- and just maybe to take a step back, I think it's really important that we clarify like what is a light client here, because, people-- we sometimes throw that term around and someone's like, "Oh, well, you know, a phone is a light client," and I would disagree, and I would say any, any situation where the user isn't running their own full node, they are in a light client, and we've used terms like SPV before, things like that. So basically your choices are, you can run your own node at home on a Raspberry No different than anything else. There, there, you know, there really are literally no trade-offs, right? 'Cause I mean, the ECDH that we're doing in silent payments is roughly the cost of verifying a signature Might even be less, but like as a ballpark, that's great. So your node is already validating every single transaction and checking the signatures, and now we're asking that node to do one more additional signature check roughly to see if this is a payment to itself. So if I've got Blue Wallet or, you know, any phone, any phone wallet that lets me connect to my own personal Electrum server Or full node, I'm just giving the scan key to that server, being like, "You do all the work for me, only tell me when you find a transaction, whether it's in the mempool or a block." Now we get this amazing UX, I've got my spend key on the phone, got my, you know, mobile daily wallet, and this is the scenario that ideally we want everyone to be in, because when you're running your own node, you're doing your own verification, which is important, and you also have the best privacy that you can possibly have, even when Now, if you can't run your full node, you now have two options. Use Bitcoin non privately and in a more trusted way, and by trusted, I mean like the server just goes away and now your wallet doesn't work anymore. and, and non privately, because you as a phone cannot download and verify blocks and transactions, so you're asking some server to do that for you. And within the spectrum of options that we have today, there really is no, in, in my opinion, and maybe this is a hot take, but there is no private mobile wallet out there. All of these wallets are using non-private backends like Electrum servers Or, or something similar. now, Bit 158 was kind of the promise of like we could build more private light clients, but people have been slow to adopt that for various reasons. and, and one of the big ones that comes up a lot is just bandwidth. Like, well, the phone has to download more data. And to me, I'm like, I agree with you, and that kind of sucks, but- I would view it more as, if you're getting privacy, I'm downloading less bandwidth than I would need to run a full node. Like substantially less data than I would need to run a full node, even in like a bit 150, a pure bit 158 world. So then it's really a question of like I mean, run a full node if you really want privacy. If you can't run a full node and you still want privacy, you're gonna have to make that trade-off with bandwidth. Now, if you want a phone that, You know, is everything except custodial, which is not private, trusting a server, you can certainly do that, but that model isn't super interesting to me, at least in like building like a mobile backend or, or a light client. So in terms of where we are today, let's take C-Cake Wallet as an example, because they're the light client that's actually implemented. They forked Electrum RS, the, the Rust one, based on some work that myself and a few other developers were doing, and they, and they modified it to where the Electrum server is now running an, an SP index. So every transaction that goes by, it summarizes the input pubkeys of the transaction and stores them in, in an index. It also keeps track of, for these transactions, does it have any unspent outputs? If it doesn't have any unspent outputs, it doesn't give it to clients. So that was the cut through that Ruben was mentioning. So the mobile phone connects to the server and it says, "Hey, give me all of the tweak data for transactions, that have happened since I last scanned, so long as they still have unspent outputs." And the Electrum server then sends all that tweak data to the phone along with, kind of a, like a simplified block or, one of the terms we've used is like a simplified UTXO, and it says, "Like, alright, here's also if you end up..." Finding a payment that belongs to you, here's all the data that you'll need to spend it. And so it just kind of sends this all in one dump, and it's at the block level, right? So again, the server only learns, "Hey, this client was interested in a block. I don't know if they found anything, you know, and, and I move on." And, so Kate downloads that data, then on the phone it does the ECDH checks, with each of the tweak data, and then uses that against the outputs that it got. So

it works reasonably well. Like, I mean, yeah, it's gonna be more bandwidth and there's that time to wait to sync. but the nice thing is because we're taking advantage of cut through there, the amount of data that you have to download doesn't scale linearly with the amount of time since your last scan. So if I scan on January 1st and then I wait a whole month to scan again, I don't need to download a whole month of Bitcoin transactions. And this was, I think, the problem that Monero was running into with their stealth addresses. The

Download, and then that very quickly gets into something that's just unusable if you've left your phone off for a month. Well, with Silent Payments, if I scan on January 1st and then I don't scan again until February 1st, every transaction that was created and then had its output spent in that timeframe, I no longer have to scan. I'm completely unaware of. So really, when I'm scanning on February 1st, I'm giving, I'm saying, "Give me all of the tweaked data for transactions that were created after January 1st." And still have unspent outputs. And so I think this gets us into something where like the UX isn't great, like in the sense that we're just gonna have to download more data, but really we have this nice feature where it's about as good as it can get, 'cause now the longer you stay offline, you're really approaching like a more constant level of data, it doesn't really go up or down, w-which is kind of nice, a nice property. Interesting. Yeah. To mention- So maybe

one, one more thing to add, is also the, Compared to the, the wallets that give a privacy, is that you cannot, you can't really check the mempool, so you don't see immediately when you receive the payments. And that's the type of thing where I think, a lot of newbie users, like they sort of expect a certain level of service, and, ultimately, like the, a wallet that really guarantees your privacy will never give you the full UX that you would desire. Like the ideal UX, i-i-is not gonna be equal to the best Private wallet out there. and so I think we have a lot of good UX wallets out there already. and now it's sort of the, the question we're trying to address is more like, how do you create the best The best possible UX for a wallet that still maintains your privacy, and that is really, that's

been very interesting. Yeah, fair point. Back to the show in a moment. This show brought to you by CoinKite dot com, the creators of the best Bitcoin hardware security devices, such as the Coldcard Mark IV and the new Coldcard Q. Now, we use Bitcoin hardware security devices to keep our keys offline, our private keys offline. Now, the way these work is you can do that setup, write down your twelve or twenty-four words on the The seed word cards and keep that secure. Now you can use this device to interact with the Bitcoin network using software such as Sparrow Wallet, Electrum, or Bep20 Desktop or Nunchuk as a few examples. Now you have a range of security features that you can use with these devices such as passphrases, you can use SeedX or my favorite is multi-signature. Now if you're starting in a basic way, just start with the device and the USB-C cable, plug it directly to the computer And use it that way, and then later improve your setup. But I believe these devices are great at helping secure your coins, especially as you start to migrate up into multi-signature security. But don't be disheartened or don't be, scared away. They are accessible, and I think you actually do learn about Bitcoin in the process. So to get yours, go to coinkite dot com, use code livera to get a discount on your cold card. This show also brought to you by mempool dot space, the leading Bitcoin and blockchain visualizer. I use it all the time when I'm checking transaction fees and trying to understand what is the state of Bitcoin's mempool. You can search transactions, historical as well as unconfirmed ones, and also see a great way to visualize things across the Lightning Network, Liquid, mining, and so much more. Also, for those of you with an enterprise, they offer a mempool dot space enterprise program. So for those of you as Part of that enterprise program, you might wanna get increased API limits, and you might wanna have increased access to the team in terms of feature requests. You might wanna have special branding in terms of how your custom instance of mempool dot space looks. So to sign up for that, go to mempool dot space slash enterprise. The lead sponsor of this show is Swann dot com, and Swann has a mission to onboard millions of people into Bitcoin. I also work at Swann, helping on some educational content. Content for the team. Now, the team have also put out a new version of the Swan Bitcoin application, which is available on your smartphone, whether it's Apple or Android. Now, this app has a really fast onboarding experience. It's now just a few minutes to go from zero to Bitcoin. So if you are standing there with your family or friends and you might have been having trouble trying to get them onboarded, well, try this now. Recommend Swan Bitcoin, and you can do this while you're standing next to them. They can click through, and most of them will be able to set up And do this in just a few minutes. Also, the team at Swan have rolled out a new promotion, there are zero fees on your first ten thousand dollars of Bitcoin buys. So this is a great way to go from zero to Bitcoin and in a guided and managed way. So reminder, go to your app store or Play Store and search Swan Bitcoin to get onboarded with Bitcoin today. And now back to the show.

we have a, a spent key and we have a, a scan key. so, the, the word view key is It's like basically an alternative for, for scan key. so, essentially there is a key that allows you to check whether or not you receive the payments. and, and that is the, the scan key. So with the scan key, you can imagine you have, maybe you have a, a hardware wallet and you have, a full node that you're running, and the full node controls the scan key. And so with the scan key, the phone know can check every transaction and see like, "Oh, was this a payment? Yes or no?" But then when you wanna actually spend it, you need the spend key. And so this allows us to sort of separate out the concern of Well, it, how do you find the transaction? And how do you spend the transaction? And the nice thing about that is that maybe your, your scanning is occurring on a device that isn't like, not as secure as a hardware wallet. so then worst case scenario, if you lose your scan key, if somebody hacks you or something, then, they will be able to basically, undo the, the privacy gains that you had, like, by, by seeing everything, all the transactions that went to you, but they won't And so that's, that's basically, the, the reason why we have two keys like that.

Yeah, and if we go back to like traditional wallets where we have xpubs and xprvs and everything like that, I think the best analogy here is, you know, I'm actually ripping this analogy off from Reardon Cody, he had a great tweet about this that I've been super happy with the description. Previously we had a two level wallet. You had the xPub and the xPriv. And the xPub was the watch-only wallet, right? That was the view, the way to view your transactions, and the xPub is what you would do when you're querying the Electrum server and be like, "Hey, do I have any transactions?" And the xPub is also what you would give to people if you're like, "Hey, instead of texting me every time, just use my xPub." And so they were kind of tied together, now with Silent Payments we have a three level

Scan key, which is the watch-only wallet, right, the xPub, and then we have the spend key, which is the xPriv, so the spending instructions, the watch instructions, and the sending instructions. And this three-level wallet design, I think, opens up a lot of really cool design space that we haven't had before. And so, you know, like Ruben mentioned, I can have my, my Spend key secured in cold storage and somewhere that's never connected to an internet device. Then I can have my scan key on my, on my Bitcoin node or my Electrum server or whatever, and if I lose that scan key, it's the same as if I leaked my xPub. Or, or my watch-only wallet. Which isn't great, right? I lose my privacy, but I don't lose access to the funds, and I can still spend the funds. the other thing that's really nice, you know, if I give you my xPub, and I give Reuben my xPub, you can send payments to me, and Reuben can send payments to me without interacting with me after that first interaction, but you guys can also see each other's payments, and you can be like, "Oh, well, it looks like, you know, someone else has been

to you, and I give my silent payment address to Ruben, and you guys can both send to me without seeing what the other person is doing. so that's kind of the overview of like the view and scan key, the, the scan and spend key, but also kind of how it opens up this new design space for wallets.

Yeah. Okay. And so the other big win that, we should elaborate a bit on this as well is, I think it's important just to explain for listeners who maybe aren't as into it, how much address reuse there is, just in general, right? Like just, I think that's the, like if we zoom out, that's really what this is, right? If we got broader adoption of silent payments, we would just see a lot less address reuse in general, and that's probably a big privacy win that people might not initially grasp. If you guys wanna elaborate on that.

I think one of the reasons they don't grasp it is because we think, "Oh, well, I don't use, I don't reuse addresses, so, all those poor suckers over there reusing addresses." And I, I don't think-- I think what people don't understand is Address reuse hurts everyone's privacy. Even if I'm not reusing addresses, but you are reusing addresses, that's creating these clusters and things on chain that people are using software to make You know, questionable claims that aren't even really based in, in real techniques and science, but just the fact that we have these clusters and these pathsing, you know, people can kind of make claims about, "Oh, this was an exchange versus not," et cetera. And so the biggest offenders here are actually exchanges, like they're the ones that are reusing the most addresses. And, and I don't blame them because if you're talking about normies and you're telling them, "You gotta use a fresh address every time," and then, you know, every time I Freak out, I'd be like, "Oh, wait, am I getting hacked? Is this the right address?" So it makes sense that they do this, and this is where I think I'm really excited about Silent Payments because I think it does have the potential to actually move the needle on on-chain address reuse by just having a superior UX and not costing the users any additional fees to use it. and that, you know, kind of indicates we might actually see broad adoption of this. So the real end game is like to get exchanges to adopt it, to where if you're depositing to

Payment address that is unique to you, the customer. And we didn't talk about this yet, but, you know, labels is a pretty import-important part of silent payments that makes that possible, where the exchange could hand a silent payment address just to you That they would know when that address is paid, that it was a payment from you. also, you know, automatic withdrawal. So there's like a lot of these DCA services. I think, I think Swan has a DCA to it. Like Swan. Yep. Yep. So perfect use case, right? Now me as the user, I say, "I want to auto withdraw from Swan using my silent payment address." And this is better than the xPub version of that, because if I'm auto withdrawing from Swan with that xPub, it's gotta be an xPub specific to Swan Manage xpubs for other people. Whereas Silent Payments now, I can have one hardware wallet, whatever, you know, where I, where I'm custodding these funds, and I can use that Silent Payment address everywhere. I can give it to Swan to be like, "Hey, I wanna auto-withdraw here," I can put it on my Twitter bio. Whatever. So I think this is kind of the usability that even if people don't care about privacy, it could move people to adopting a superior UX and something that they more expect from a payment system. And by doing so, we've trojan horse'd in the privacy by getting rid of the address reuse because we've abstracted the on-chain address away from the user. You know, let, let's, you know, imagine for a second, adoption takes off, everyone's using silent payments You would get to a world where people don't even really understand, like, the underlying, like, they don't even really care, and I don't even think that they should, about what actually goes on chain. Now we're the early adopters in Bitcoin, we understand the tech, so I always talk about, you know, what happens on chain. But like, if I send money through the fiat system to a bank routing number I have no idea what's going on under the hood, and I don't care. And I think that's kind of a way where we win this privacy problem with address reuse is we solve the UX problem for the user. We understand, "Why were you reusing addresses? it was a UX problem. Let's solve the UX problem. Let's abstract away the details of what's happening under the scenes so then we can implement it in a very private way without asking you to care about it. " And this is where, you know, we don't get these opportunities a lot. In privacy. It's usually you need to pay more for privacy or you need to use more complex protocols, and Silent Payments was one of these unique ones where it's like, "Well, wait, what if we just solve the UX problem for people in a way that's incentive aligned?" And then as they adopt it, because of the UX benefits, then the privacy gets better because we're seeing, you know, less address reuse. so that's, you know, pie in the sky version is silent payment addresses in every exchange, 'cause then I think that would make a huge dent in the on-chain address that we-- on-chain address reuse that we see.

Yeah. Great. So, yeah, as you were saying, it's, it's the combination, it's sort of this marriage of a privacy improvement with the UX improvement that's actually gonna more likely to get it adopted. yeah. So, one other area, as you were touching on, if you go, if you guys could explain the labeling concept, yeah, with Silent Payments.

That's, that's definitely, something, so that's, Something that came up, like, like after I, I wrote up the initial specification and the idea, the labeling thing was always just sort of like, it, it was something that people were mentioning as a downside, like, "Well, what if you actually want to know who is sending you the money?" because like with silent payments, by default, you don't really know who, who is sending. and so I thought about that, and the, the labeling, thing is, is what I came up with. and so one, one naive way to do it is, creating a new silent payment address for everybody who's paying you. but if you do that, that, that is, basically, it, it, blows up your scanning costs, right? Because for every user, you have to now scan every transaction, so that's just not scalable at all. A-and so this is sort of a middle ground where, because like with a, a new silent payment address, you could essentially, you wouldn't even be able to link the identity, right? Like, like I, I could generate two silent payment addresses and I could pretend to be two people online and there would be no link between the two. But with labels, essentially, the, I came up with like a neat, trick to allow you to basically add a little bit of extra data, into the, into the address. and so the way this works is,

like, like we mentioned earlier, we have a, a scan key and a spend key, and basically we, we tweak the spend key in a deterministic way, and on-chain when you're checking for payments you basically do an additional check, to see, hey, which spend key was, did this money go to? Then, depending on which spend key it, it went to, it tells you something about, the recipient. So you, you could generate essentially, what is the equivalent of a different spend key, for every user on an exchange, and then the exchange, when they're scanning, they would have to do one additional calculation, which is, which can be very cheap because it's basically just a database lookup. to check and see, okay, w-who, which, which spend key did this money go to? and so this basically allows you to com- to, the sender to communicate something extra to the recipient, that the, the recipient, you know, includes this data basically in, in the address that they give to the sender, prior to receiving money. but this, this is essentially, how it works. and the, exchange use case is just one of the But you could also have a use case where, let's say I'm, I don't know, I'm on Twitter and I'm a Macedon, and, I have, two silent payment addresses on there. i-it's clear to everybody that they're the same, the silent payment address belongs to the same identity to me, but the, spend key will be different. So basically the way it will look is, the first half of the address will look exactly the same, and the latter half will look slightly different. and, now when I'm receiving money, I can see like, "Oh, these are Mastodon users that were paying me," or, "Oh, these were Twitter users that are paying me." And so it gives me a little bit of extra information. And, so that's a, a really neat feature that sort of like, allows us to kind of have the best of both worlds, right? If you want Perfect privacy and the sender doesn't want to reveal anything about themselves, then they just use your general, your main silent payment address, but if you, if you need a use case where you need to learn at least something from the sender, then you can utilize this.

Okay, great. now contrasting or let's sort of say when you're adding in Lightning to this picture, right? Now obviously they're different protocols, right? We're talking, we're dealing here with on-chain payments, so generally speaking, these are larger payments, whereas your smaller ones you do that on- On Lightning, I guess that can make things confusing again for, you know, if people just wanna have like one QR code that they put somewhere to take their donations, where maybe currently they might use a Lightning address, or maybe in the future, that would be a BOLT twelve address, if they're, if they're dealing with smaller payments, let's say. so do you guys have any ideas on what, how to sort of square that circle? Are you gonna, are we gonna have contact lists in our, you know, in our apps that sort of talk about, oh, this is Jos

The big payment now we need to deal with is SP code, his silent payments code, or do you have any ideas on how to marry the two?

Yeah, and, you know, I kind of hinted at it earlier, The silent payment address is abstracting away what's happening on chain, and I think eventually we should get to something that's abstracting away what's happening on Bitcoin from the user. And so, you know, pre- previously, we've, we've, we've had unified QR codes with Bit Twenty One, so I think that's like kind of the first most natural place where you have this URI that presents a couple different options, and there's one single QR code, and the wallet, the sending wallet, reads that QR code and then picks the one that either they're able to or they prefer. So that's kind of the first step towards that. even more exciting, Matt Corallo, the Blue Matt, proposed a bit a couple months ago that was like human-readable, the

human-readable names thing for Lightning, yeah?

Yeah. So this is really exciting. I'm, I'm super stoked about that because now you have, Without getting too many into the details, it's using DNS, SEC to make it like more secure, but you have this way to have like Josie at josie dot com, whatever my domain is, or, you know, maybe I've signed up with a wallet provider, Josie at blue wallet dot com or Josie at cape wallet dot com. And then when you wanna pay me, you just send money to Josie at blah domain dot com, and the wallet is doing some lookup to get the payment instructions for me, and that payment instruction is returned in- Some sort of unified, you know, either a Bip twenty one URI or a unified QR code or whatever we wanna talk about, and then the wallet makes a game time decision, what's the best way to pay this person? If the person communicates a Bolt twelve static offer and I can understand a Bolt twelve static offer, I'm gonna use that. If the, payment includes a Bolt twelve static offer with a fallback to a silent payments address, then I'm gonna use the silent payments address if I'm not a lightning wallet, et cetera, et cetera. To the user, And, and we've just kind of built this nice layer on top of it, which gets away from this like, you know, you've seen these donation pages in Bitcoin where it's like, "Here's my Taproot address, here's my SegWit address, here's my Bit 47 payment code, here's my Lightning, you know, address, here's my Volt 12 off," and you're just like, "Oh my God, like this is, you know, for us that love the tech, and, you know, we're like, "Oh, this excited is up until we had bit three fifty two, about, up until we had silent payments, we didn't really have something that would just go right along with a bolt twelve offer super easily. Like had we used, you know, bit forty seven or one of these other ones, there would have been this weird, you know, I make the payment, I wait for an on-chain transaction, there's weird setup ceremony. That's the notification

transaction style just limits what you're possible, yeah. And then, then it all

came together and, and, you know, right at the same time that Matt

Then we were finishing this on Payments Pip, I was like, "Holy shit, we're-- it's all coming together where it might actually be possible to have this super clean privacy by default UX on Bitcoin." And, that's what I get most excited about.

And so speaking as well broader, I think there's this idea, and I was, oh, yeah, I think you and I were talking about this kind of on Twitter or X before, this, we have to kind of get people away from the silver bullet mindset, right? This idea of just this one technology, this one It's more like we need multiple tools. Maybe it's like silent payments and Payjoin adoption and Bolt twelve and human readable names, and you, you kind of pull these pieces together, and now we're starting to answer the question, right? And I think this comes to the other point, which, people might have seen Edward Snowden sort of came out making some comments saying, "Oh, and..." I, I kinda disagree with a bit with his framing, but the way he framed it was kind of like, "Oh, these Bitcoin dev-- I've been telling these Bitcoin developers for years, they need to pull their finger out and start focusing on Bitcoin privacy on chain." And, you know, it just kind of, it seemed a bit out of touch with how actual Bitcoin works. And first of all, Bitcoin developers aren't a monolith, there are many of them, they disagree. So it just kinda seemed a bit weird to me. But I'm curious if you guys have any thoughts in

for Bitcoin privacy.

Well, I, one, one thing I think that's always important to sort of realize and think about is that, like, if you take something like Monero, they have they use a, their transactions are a lot larger and the, CPU, is, like you, you do, you have to do a lot more work, you have to download a lot more data to get the same amount of, the same number of transactions. So it's, it's not like you get it for free. so that's the first thing to realize. you're gonna have like, y-y-you know, you would have the equivalent of maybe a one hundred kilobyte block size, Privacy, it might, might even be worse, so that's, that's sort of, sort of one thing, to keep in mind that there, there's a cost to it. and, you know, there are other costs too, of course, where, i-if you don't see the actual, the, the amounts on chain, then that can lead to problems, if you, if you have some kind of, bug in the system. so, so there are, there are a In theory, if we could have more privacy on chain, on layer one in Bitcoin, with zero costs, let's say, right, like no trade-offs, then the answer I would give is yes, let's do it, right? So, I don't think anyone, would be against it necessarily. the question is more like, is it, is it worth it? and do we want to, essentially allow for fewer transactions, but have them be more private? and I think the, the answer- Answer to that might, might be a yes if, it turns out that there's no possible other way of, of receiving privacy, right? If, if you can't get privacy any other way than just having the base layer be private, then, maybe that is what we would have to do. but, there are a lot of other options out there. there's CoinJoin, there are, there's a bunch of research into like layer two protocols that, that might, might help. we Things like ARC, for instance, that i-that is inherently trustless but also works as sort of a mixer. so, so there are a lot of options out there. so it's not necessarily a given that we need to make base layer sacrifices to get privacy.

and so that's, yeah, I, I think it's a difficult question to answer ultimately, but I think that's at least what's g-good to keep in mind, like it, it doesn't come without trade-offs.

And I would even take a step back from the privacy framing, right? And, and, and more just where my- I guess strong theory of the case, like how I think the world should be, comes less from a privacy standpoint and more from a, an engineering standpoint of, you know, when you're designing something, I think you should do one thing really well, and you should play well with others. Those are the two, and, you know, to put those in more technical terms, it's, it's, it's like the, the Unix philosophy. Small tools that do a task really, really well, but also compose well with other small tools. So compositability is kind of that play well with others Just in general, privacy is gonna be better when we stop trying to build the silver bullet or, you know, the Rube Goldberg machine that will do everything, and we look for ways to identify what's the problem here. Let's solve this problem super efficiently, as elegantly as possible, and then let's make sure it composes well with other things. So Silent Payments is an example. It was just to tackle this one problem of interactivity with payment instructions and getting rid of the, the bad incentive to reuse addresses. That's all it focuses on. And then people were like, "Oh, well, you know, the on-chain, if I consolidate the UTXOs," I'm like, "Yeah, yeah, yeah, yeah, you're talking about spending privacy, that's a totally separate problem." And then they're like, "Oh, no, no, no, Bit 47, you know, solves that," I'm like, "No, no, no, it Separate, distinct, and then, you know, at the application, the mobile wallet, the full node, whatever, now you combine these things together and you get a more comprehensive privacy solution by Stringing all the little tools together, and I, and I think that's just the right approach, whether you're building for privacy or, or, or anything else. And, you know, I think, you know, we've, we've talked a lot about Bit 47 because it's the one that had the most adoption, but I'll, I'll use that as, as a cautionary tale. I think one of the mistakes they made in the protocol with Bit 47 was it was really designed around this merchant Customer use case, it says it in the BIP, and, you know, maybe privacy was even an afterthought, right? It, it wasn't really meant to be like a private protocol, and that's why they made certain decisions, like every time you make a payment in BIP 47 and establish a channel, you're sharing the send-- the payment code of the sender. Now, from a privacy standpoint, I'm like, that's a horrible idea. Like, I, I would, you know, if I put my payment code in my Twitter, and then I wanna go use, And maybe people aren't aware of this, it's just a very bad decision, I think, to make in a privacy protocol, but it's more because they were trying to do a bunch of different use cases. They're trying to make it work for a lot of different things. And so the analogy with Silent Payments is, Silent Payments does this thing really well, this non-interactive, fully private, and then if you want that, like, customer merchant refunds, well, then you can add labels on top of it, and you can, you know, do whatever. and if you wanted contacts 32 address, why, why isn't it, you know, like a simple-- I'm like, okay, that's something you can add on top of silent payments. you know, expiration dates came up when we were talking about silent payments. Someone was like, "Look, if it's gonna be static, it needs an expiration date." And I'm like, "That's a separate problem, right? That's a, you know..." Address data becoming stale over time is a totally separate problem that needs a different design space. Now, I'm not, I'm not saying that's not important, I'm saying we should have a silent payments protocol that does reusable addresses really well, knocks it out of the park, and make it composable with something that does expiration dates or revocation really well. So, you know, you, you mentioned Payjoin and some of these other things, I think the perfect solution for privacy is we keep, as developers, as a community, picking the problem that we have domain expertise in, that we really care about A really simple solution to that problem and ensuring that that really sim- simple solution operates well with other solutions, because the best privacy isn't gonna be this be-all-end-all bip or wallet or protocol, but it is gonna be a wallet that can do silent payments and payjoin in a way that, you know, they interop together. a lot of the design and silent payments went into making sure that we were gonna be compatible with Coinjoin. So rather than build like the Silent Payments CoinJoin protocol, be like, "Hey, let's build Silent Payments, and then let's figure out, and let's make sure that we don't back ourselves into a corner so that this is composable with CoinJoin." And I think in terms of privacy and engineering, that's the philosophy that we, we more need to take of like simple problems, simple elegant solutions, and then combining them together.

Yeah, really well said there. And I think the other thing, the, the thing that I was thinking about as well is, so, let me put it this way, the big thing with reusing addresses is you're giving the outside observer a starting point, right? That's like the big thing. You're just giving them the starting point. Now, of course, it's one thing, it's, it's one thing if the exchange knows your coin, like, at least where they sent the coins, 'cause they're the ones who sent the coins. Do you? Right. So they know that starting point, put it that way. But an outside observer, in the case where you're not reusing addresses, they don't have a great starting point. They don't necessarily have a great starting point. And then from there, that's where the chain analysis kind of, okay, this hop, that hop, that hop. Now, to be clear, there's lots of, there's lots of heuristics, right? But the probably the main one is the common input ownership heuristic. There's other ways in which your privacy can be impacted, things like

approach there. Maybe there's the internet, you know, level, you know, the what IP broadcast the transaction or what IP was asking for these transactions from the Electrum server. Oh, okay, now we've got you from the IP side, not the transactional graph side. So there's kind of all these components to it for somebody who wants to be private, and the reality is that you're, in most cases, gonna have to pay more or kind of do more work to stay private. so I think it, it seems likely to me To me, if we had to kind of speculate a bit about where it goes, like let's say we got silent payment adoption, let's say we got more pay join adoption amongst the wallets, so now the common input ownership heuristic is being undermined. You know, so you kind of, you're giving them less of a starting point, and now when you're spending, you're not kind of giving off clues about, you know, exactly where those coins are going and who, whose coins belong to who, because the wallet clustering requires these heuristics to be able to do it. Now, to be clear It's not just common input ownership, it's output type or input type, it's the ordering of the inputs, there's end sequence numbers, there's kind of all these ways that people try to fingerprint different wallets, but I guess these are the ways to sort of take away the, the low hanging fruit, right?

Well, and you've used the term heuristic multiple times because that's what they are, right? It's not a guarantee. Everyone's looking at all of these different, you know, bits of entropy and trying to kind of pull it all together to get a fingerprint or a heuristic. And so I see a lot of value in frustrating the heuristic, like that's all you have to do to really be effective. we don't need the be-all, end-all solution, which some of these like privacy at the base layer things kind of try to do. And instead, I think if we can frustrate the heuristic to a point where it'll be like, "Hey, you can no longer..." accurately claim that because I can demonstrate, multiple instances and, and, and a certain percentage of instances that are happening that go directly against your heuristic, it's enough to sow doubt In, in the heuristic that's being applied. And also, I think what you said about starting point is really great of,

it's really hard to get back privacy that you've lost in Bitcoin because there's a permanent ledger. Right, that is replicated around the world, you know, and everyone has access to. So I think, you know, starting here and saying like, "How do we make sure that from the get-go, you're not making horrible mistakes that will then be tracked throughout the rest?" is a really good place to start. And then when we talk about on-chain, I think really where we gotta focus on is how can we make sure that there's enough ambiguity as to what's happening on-chain, that even though you can see what's happening, you can't make definitive claims about it. which Which is why tools like Payjoin, Coinjoints are really powerful in, in, in, in frustrating those heuristics, because they give a counter narrative. You know, the common input ownership heuristic says one person owned all these coins, and then Payjoints and Coinjoints come along, they're like, "That's not true, and I can give you plenty of examples otherwise." And if these things see wide enough adoption to the point where they're not costing the user more to use them, then I think we get into a place where a significant amount of, transactions just don't Well, like, silent payments, you know, the BIP defines and says when you send to a silent payment address, you have to create a taproot output for them. and early on, there was some criticism about that, and they were like, "No, you need to give the recipient the option to specify, like, a bit that says, 'I want legacy addresses' or whatever." And we're like, "No, like, if we have a choice to kind of lock down the optionality of how you use this proto-protocol in a way that makes it more private

And we don't know if these Taproot outputs are silent payments, Lightning channel opens, or, you know, MuSig's or Frost, everything starts to look the same on chain. And that's really the world I think in Bitcoin privacy we have to keep pushing for, and anything we can do that kind of moves the needle toward that, I think we're gonna end up in a much better place. You know, some of my early privacy work was around all of this like script type heuristics, and everyone was like, "Oh, you just gotta match the script type of the change," The more uniform the, the activity on chain becomes, the less and less of a problem some of these things are, and the solutions become easier and easier to build because you don't have to account for this giant matrix of all these different flags and fingerprints to worry about.

Yeah. One other area I'm curious if you see any, I mean, in the same way as you said to the composability point, do you see, as an example, when Lightning nodes open channels with each other, is there something there, or maybe when Lightning nodes do like splicing in and out of channels? Channels. Do you see any thing, any sort of applications to it there or not really?

I, I, you know, this people have asked this, I would say not really. I mean, well On, on the implementation side, so we, we talked to someone from, who, who was working on Core Lightning, and they mentioned, you know, one of the annoying things about having xPub is state management. I have to Do the gap limit, and I have to make sure that I'm not, you know, handing out an address that I've already handed out, and that makes software more complex. And I would say Silent Payments is a very elegant solution to that because it's like, don't worry about it. Like Silent Payments is a stateless protocol, there's no state management, you just hammer it with CPU. And so it's very simple, and you just hammer it with CPU. And I think from like a code, you know, implementation standpoint, that's really attractive for some of these things where instead of handing

A, a benefit I would say, and the gap limit can just be really annoying. on the other hand, silent payments really shines with non-interactivity, like that's really kind of what we were going after there, of like, right, this way of-- Whereas, like, we're already talking to

each other, yeah.

Yeah, I mean, if you've got interaction, you know, and, and, and you can do this securely and you've got all the infrastructure to do it, I don't see any reason to prefer a non-interactive protocol, unless you're trying to further interactivity as much as possible. It's complex as hell, it's the death of privacy, it just makes, it's buggy, et cetera. so if there is an option where someone can replace something that they were relying on interaction with, with silent payments, then I'd say yes. but beyond that, I'd say, you know, look, if, if you got interaction, just do, do what you're doing.

Yeah, totally fair. Okay, so I think we've covered a lot of stuff here. obviously this, you know, probably a good Key benefits, I see it as cutting address reuse and making it a lot more like a contact, Bitcoin username. I think having that user experience win, right? It's not just a privacy win, it's a user experience win. I'd say those are probably the two focus areas for listeners who, if you're not that technical, you just kinda wanted to get a rough idea, what is this, what is it gonna help us with? I think I would say if you're a listener and you are maybe in some wallet, Telegram chat or Discord or something, maybe you can push them to say, " Hey, why don't you get silent payment payment support, right? And if you can at least start on that side, starting to kind of encourage your, you know, communities to kind of push for silent payment support in terms of making the payment, and then eventually once there's enough payment support, then there'll be enough wallets and wallet developers who are like, okay, let me code up silent payment receive support, and then now we will start to see a world where donations become a lot easier and just kind of regular transactions become a lot easier Kind of easier. And it would be cool if exchanges adopt this, obviously. so I think that's probably my high level summary. Do you guys have any closing thoughts for people?

Yeah, I, I think that's an excellent summary for one. Josie, you wanna add something?

Yeah, so we've got a lot of, activity on delving Bitcoin right now. So we started a silent payments working group. it's, you know, any, anybody's free to join the working group and post there. And so someone had reached out to me and A discussion on how we're gonna get PSBT support for silent payments. I think that's a pretty important one for wallet, for wallets. I'm also working on a descriptor BIP for silent payments. So like, how are we gonna make sure that silent payments, you know, are interoperable between wallets in a really clean way? And I think descriptors are the best solution we have for that. So I'm gonna be posting on Delving for that in a couple days. we've got, you know, so a lot of things that happened when we were talking about Which is a Rust library for Bitcoin 158, and then someone else built something in Go called BlindBit, and then the Silentium wallet also has Silentium D as the index. So, I was kind of watching all that happen and, and kind of pushed a few of these people to be like, "Hey, start a post on Delving. Let's start to standardize like a light client protocol, so that, you know, if you build an index and I build an index, you know, wallets can use multiple indexes, just like, you know, the Electrum

Payments happen, just join the discussion. We want as much input from wallets as we can get, and there's still a lot of, you know, doing all the implementation details, there's a lot of work there. If you don't really care that much, then yeah, just implement sending support, because I think, you know, the sending support is really important for adoption. I also think- You know, there's the, there's the silent payments today, like getting it to work with everything we have today. eventually, one of the things that I would love to see someone do, just 'cause I, I've been wanting to do it, but I don't have time, is get some support for these personal servers. So we have the, you know, Electrum, Focrum, things like that. To me, that's a no-brainer. Just add a silent payments index to that, have a user register their scan key so that, you know, the index can Mobile wallets already support a user running their own server. So to me, that's like a really low-hanging fruit. Let's, let's cert, you know, let's get something that works for the people who are using Bitcoin privately today, the people who are running full nodes, and then we'll keep working on the, on the light client problem. but yeah, I'd say get involved on delving if you're in the technical community. If, if you just wanna use Silent Payments, then yeah, talk to your, talk to your wallet provider of choice and, really push

Great, well, I'll put the links in the show notes for listeners as always. Josie and Ruben, thank you for joining me today.

Yeah, thanks for having us. It was fun to catch up.

I hope you enjoyed the show. If you did, make sure to give it a thumbs up and share it out there with your family and friends. Check out my website at stephanlivera.com, and I will see you in the citadels.