Silent Payments - Episode 58

Aaron van Wirdum Live from Utrecht, this is Bitcoin.

Sjors Provoost Explained.

Aaron van Wirdum Hey, Sjors.

Sjors Provoost Yo.

Aaron van Wirdum Hey, Ruben.

Ruben Somsen Hey.

Aaron van Wirdum Ruben is back. I think last time in Prague, we were all in Prague last week. And there I introduced you as our resident funky second layer expert.

Ruben Somsen That is right.

Aaron van Wirdum This week we're going to... talk about one of your new proposals, which is actually not a second layer proposal.

Ruben Somsen True.

Aaron van Wirdum You've promoted to the base chain.

Ruben Somsen [unclear] Thank you.

Sjors Provoost Welcome to the base chain.

Ruben Somsen It's good to be here. Thank you.

Aaron van Wirdum So yeah, we're going to discuss silent payments.

Ruben Somsen Yep.

Aaron van Wirdum This is a proposal you made recently, right?

Ruben Somsen Yeah, it's a recent proposal, yeah.

Aaron van Wirdum Yeah, so you proposed this a couple months ago, but I think the general idea is also older, right? Very old. It's based on an old idea called stealth addresses, I think, originally proposed by Peter Todd years ago.

Ruben Somsen Yeah, 2014.

Aaron van Wirdum Right. And this is... improvement on that, an iteration on that? How would you describe that?

Ruben Somsen Yeah, you could say that. So the interesting thing is that the original proposal, I think the idea is kind of old, but the downside of this version is that you have to do a lot of work, essentially, to recognize that you got paid.

Aaron van Wirdum Of your version.

Ruben Somsen Yes. And I think in the past, it's not like people didn't think of that, but at the time, it seemed like that was going to be too much work. And Bitcoin has improved a lot over the years. So actually I think sort of like that that thinking never got updated. Uh and now we're at the point where we can do uh these these kind of the verifications of blockchain quite quickly, right and the uh the the library that we use libsecp 25— 20— what— 256k1 Um, that library is very fast now. So basically, it made it more viable than it was back in 2014.

Sjors Provoost And for the loyal listeners, we did an episode about libsecp256k1. I think it's episode two.

Aaron van Wirdum Really?

Ruben Somsen Oh, wow.

Aaron van Wirdum That's short for you. You'll remember everything. Okay, so we can maybe get into the comparisons later. But for now, what is the general... idea what's the general problem that we're solving?

Ruben Somsen Yeah, so kind of a good way of putting it is that generally speaking when you want to make a payment you have two options. Someone can give an address and you can reuse that address and continually pay that person on the same address. And if you do that then you lose all all privacy, because every time you receive a payment I know it's your address and then maybe you know Sjors sent some money to you and I I can see how many bitcoins you have etc etc Um, so because that's a problem generally what we do is let's say Aaron if I want to send you a payment I I tell you I say like hey Aaron I want to send you some Bitcoin could you please give me an address? And you're sure here's here's an address and every time I want to pay you you have to give me that address.

Aaron van Wirdum Well I'll generate a new address every time right?

Ruben Somsen That's what you generate a new one

Aaron van Wirdum Yeah ideally a fresh one.

Ruben Somsen Yeah, and so, This proposal, silent payments, allows you to basically have a single static address and allow me to derive an address from that, that nobody can recognize except for you and me. And so this makes it basically, it makes it the same process, but now it's non-interactive where I don't have to ask you for an address. And that is particularly useful when you think of things like donations, where there's a cause, the cause posts one single address and everybody goes and donates to that cause and no interaction is required. So that is basically the proposal.

Aaron van Wirdum Right. So if I want to accept donations, then I'll post this. No, it's a stealth address, but you're not calling it a stealth address. You're calling it a silent payment address, right?

Ruben Somsen Yes, just to differentiate. But it is essentially a form of stealth address.

Aaron van Wirdum Same idea. So I'm posting this quote-unquote address on my website, and then you, Ruben, in this case, can generate new addresses from this?

Ruben Somsen Yes.

Aaron van Wirdum And send money there and then somehow I should be able to spend from this address that's kind of where the trick comes in that is like how can I spend money from addresses that you generated Yes. Okay. Ruben, how can I spend money from addresses that you generated?

Ruben Somsen Sure. Essentially, what we do is we generate a shared secret. Generating a shared secret is done by taking two public keys. You have a public key, I have a public key. Because we both know one private key, you know your private key, I know my private key, we can do this calculation, which is basically a multiplication. That allows us to generate a number that you know and I know, but nobody else knows. And with this number, we can then generate a key that is sort of shared between us. So it's a public key. You could set money to that key. But if I were to set money to that key, both you and I could spend it. So that's not quite good enough. So we add one more step after we have the shared secret, which we turn into a shared key. We then add your public key to it. So now it's a combination of the shared key plus your key. And that combination is something that only you know, because I don't know your public key. I don't know the private key behind your public key.

Aaron van Wirdum Okay, that's a lot of information in one go. So let's break it down.

Sjors Provoost So what we did was a Diffie-Hellman exchange plus something else.

Aaron van Wirdum Right, exactly. So, Sjors.

Sjors Provoost Yes.

Aaron van Wirdum What is a Diffie-Hellman exchange? That's the first part we can break down here, I think.

Sjors Provoost So Diffie-Hellman was a famous rapper. No.

Ruben Somsen I wish.

Sjors Provoost Basically, the idea, it's being used in browsers too, for example, right? So when you connect to a website that's secure, they have a public key. The website essentially has a public key. And you on your computer generate another public key. And you basically tell the web server, hey, here's my public key. And then the web server can send you information in secret. And you can send the web server information to that secret. And so this really uses a very nice mathematical property, which is that if you take a private key A and you multiply it by a public key B, that is the same as when you take public key A times private key B.

Aaron van Wirdum Yep, right.

Sjors Provoost So that means that, well, with Bitcoin we have addresses, which is essentially just a combination of a private key and a public key. So if I know my private key, obviously, and you know my public key and vice versa, then we can create a shared, essentially a shared address, a shared Bitcoin address, where we both would own the shared Bitcoin private key and we both would own the Bitcoin shared public key. But this would be utterly useless because if either of us sends money to that, then either of us can steal that money. We don't want that.

Aaron van Wirdum Yeah, okay. I'm following you, but that's also because before we started recording, I had an hour to try to understand this. So to summarize this real briefly, the Diffie-Hellman exchange, two people have a public and a private key, and then multiplying one public key with the other private key gets a secret number. Right so and because both persons know their own private key and the other person's public key they can both generate this number but no one else can generate this number because no one has either no one else has either private key yeah okay so from this secret number you could potentially create a Bitcoin private you could say that's a Bitcoin private key essentially yeah and have a public key and then So basically what you were just saying, Sjors, is you could use that like if Ruben wants to send me money, he could use that. Well, he couldn't, but he could send me money to that Bitcoin public key. And then we both have the first key. So the problem is then Ruben can just take the money back. I would have been paid, but I wouldn't because Ruben can claim the money back.

Ruben Somsen It could be a future.

Aaron van Wirdum So we need to add one more level—level, right?

Ruben Somsen It's a reversible payment maybe exchanges would like this right they send money and they can take it back just kidding.

Sjors Provoost Or you make it a two-step process right where you receive the money on this common address and then the other side sweeps it away yeah and once it's confirmed but that would mean two transactions for one but we really don't need to do that

Aaron van Wirdum Yeah, so I'm I'm I'm not sure if I just made it more confusing for the listener. This is the way I understood it. So maybe that helps. So like you you could now generate a Bitcoin private key and a public key however if you send money to that that's not secure because you can claim the money back. So there's one extra step that needs to be taken here what's that extra step? Yeah.

Ruben Somsen Yeah, so the extra step is that we take that shared secret that shared key and we add the public key of the recipients to that shared key.

Aaron van Wirdum Right, so this is the same public key that I was sharing publicly the silent payment thing that I had as a donation address, yeah and we now add the shared uh am I no you finish this sentence for me before I say it wrong.

Ruben Somsen Yeah, you add the shared key to it, right which is a derivative of the shared secret.

Aaron van Wirdum And in this case when you say adding it to it it's basic it's kind of like creating a two out of two multi-sig yes, except we use cryptographic tricks it's not actually a two of two it looks like a [unclear] but it's sort of… it is kind of like a two of two, right?

Ruben Somsen You could think of it in that way. But essentially, basically, we're using the fact that you can use elliptic curve cryptography in a way that is basically like regular math, where you can take someone's key and you can take someone else's key and you add them together. And if you do this with the public keys, the private key is also the addition of one private key with the other private key. So we have two private keys, essentially. And by adding... By adding those two together, we generate a key that only you know, because I know one of the private keys if I were to send a payment to you, but I don't know the other one because it's your key.

Aaron van Wirdum Right, so the two private keys that we're adding together, to be very clear, are the shared secret private key that you were able to generate in combination with my public key, and then my actual private key that... corresponds to the public key that I posted. So that's the two that we're adding together to create a new private key and a new public key. Well, I'm the only one who can create the new private key because I'm the only one who has the private key that corresponds with my public.

Sjors Provoost Maybe I can illustrate it from the other side, which is that if you just published your stealth address and we don't use it as a silent payment address, if you just publish an address, then anybody can send to it. It would just be a regular transaction where you only have the private key and I have the public key. The downside of that is that everybody can see what's going on. So what if you just add something to this regular address? So you're adding a shared key to the regular address, essentially. That might even be an easier way to understand it. So we just explain how you make the shared key. Then we say we take a regular address or a regular private key. We just add a shared key to it so that nobody else in the world can see what's going on.

Aaron van Wirdum Okay, so you, Ruben, you were going to send money to my donation address. Now we've tried to explain how that works. We've explained how that works. I hope people have been able to follow that.

Ruben Somsen Yeah.

Aaron van Wirdum So you're sending money to that address.

Ruben Somsen Yeah.

Aaron van Wirdum Now the question is, how do I know that you did that? And how do I actually generate the private key that corresponds to that? Because I need to know about it, right?

Ruben Somsen Yeah. So the first thing you need is you need to know the key that I used in order to generate the shared secrets. Because you know your key, obviously. And I know your key because it was publicly online or your Twitter profile or whatever. And so the key that I use is one of the keys of the inputs in the transaction that I create. So if I want to send a payment to you, I create a transaction. The transaction has inputs. The inputs have a public key corresponding to them. And I know the private key of those keys.

Aaron van Wirdum This is just a Bitcoin private key, public key, just a public key that you were using anyways, that has your money on it, right? Okay. Yeah.

Ruben Somsen So when I create that transaction, I pick my inputs and that is the key that I use to generate the new address that only you can spend. And that is where I sent the money. And so the second step, so this is how I make the payment. But the second step is for you to recognize that I actually did that. And that is sort of the tricky part and sort of the downside, I would say, of this proposal, which is that in order for you to recognize that I made a payment, you have to go and check every transaction that appears on the Bitcoin blockchain. And you have to go and see if it is a payment to you. And the way you do that is basically the same way we generated this address. You're also going to generate the address and you're going to see… So you're going to take the inputs, you're going to generate the shared secrets, add it to your own key, see if the result is one of the outputs. And that is how you recognize whether or not you got paid. So it's a lot of effort, but the effort is all on the recipient side. And if you're running a full node already, it's relatively not a lot more effort.

Sjors Provoost So basically every input of every transaction on the blockchain could be, as a recipient, could be for you. So, yeah. So that means you have to inspect every single transaction that's on the blockchain. And for every input of every transaction, you want to add your shared key to it. And then that generates an address. And you then see, hey, is this transaction actually spending to that address? If so... boom, you just essentially add that address to your own wallet, and then it just functions as any other wallet address would function.

Aaron van Wirdum Well, I guess it's already the case that you need to check every transaction to see if there's an output for you, right? Yes. So the new part is that you have to do some extra calculations to see if the inputs...

Sjors Provoost But it's definitely a lot of extra work, right? So normally what you do is when you see a transaction, you only care about the outputs. I mean, you care whether the transaction is valid at all. That's why you look at the inputs. But... the outputs, the only thing your wallet needs to do is look at the scriptPubKey of this output, so basically the destination of the output, and then compare it to the list of addresses or scriptPubKeys in your own wallet. So that is just comparing one list to another list. That's very cheap. But in this new scheme, you need to do basically elliptic curve key multiplication on every input. And then that gives you an address. So it is significantly more work than just looking at a list.

Ruben Somsen Yeah. And to give a sort of approximate idea of like how much work that is, it is as if you check every signature twice instead of once. That is sort of a very rough way of saying it.

Sjors Provoost Yeah, so it definitely increases the time you need to verify blocks. But if you look at that from the perspective of your node is running, it's already synced, and it's just running, then one block comes in every 10 minutes, your node will verify that block in a few seconds. So maybe it'll take half a second longer. That's fine. The bigger barrier is when you first want to sync the whole node. If you want to restore from a backup, things get a little bit more hairy. But I think we can get into that later.

Ruben Somsen Yeah, that is something actually I would like to get into now, perhaps, because so there are…

Aaron van Wirdum Ruben is taking charge.

Ruben Somsen Well, I think if we do it later, it's going to be more confusing.

Sjors Provoost It's called Bitcoin Explained now.

Ruben Somsen Exactly. Yeah. So, There are a couple of things you can do to make this process faster. And so as Sjors was saying, once you're at the tip and you're validating and a new block comes in, you just have to validate everything. But one of the things you can do is there are a couple of things you can do to sort of speed it up when you resync a node and you have an address and you want to know if there's any outputs that are yours. So the first thing you can do is simply have a birthday on your key and say, okay, well, I created this key in, let's say, 2022. So let's say January 2022. So from January 2022, I go and I check every block. And before that, I don't even bother. So that's one thing you can do. Another thing is that this protocol in principle is going to only create Taproot outputs. So any transaction that doesn't have any Taproot outputs in them can be ignored. And so you don't have to check those transactions. Um that is sort of a thing that saves a lot of effort right now because we don't have a lot of Taproot transactions yet but you know in time eventually everything is going to be a Taproot transaction at least that's the hope uh so it's the kind of it's an optimization that helps today but won't help tomorrow let's say. Yeah. Um and then the biggest one is that instead of validating every transaction from the entire history what you can actually do is you can take the UTXO sets and only check those outputs and see if any of those outputs correspond to a payment that belongs to you. And the downside of this is that you will have no history, so you won't be able to see any outputs that were yours and were spent, but you will find all the outputs that were unspent. And it also requires a bit more of an additional database that ties the inputs that you might require to do this calculation to the UTXO and UTXO set. So there's a bit more complexity there, but the benefit there is that basically instead of scanning the entire history, you can now just take the UTXO set, scan that, and find every unspent output that belongs to you.

Aaron van Wirdum Right, yeah. And then you'd need to somehow get the inputs that... That refers to the output. Yeah, okay.

Sjors Provoost Yeah, so when you look at how a node is actually built, and Bitcoin Core is built in one way, but maybe libbitcoin is built in a very different way, there are certain pieces of information that are very easy to access and certain pieces of information that are a little bit more work to access, and that can really matter with a proposal like this. Because if the information, for example, is sitting in your RAM memory, That's very quick to access. If, on the other hand, you need to go on a disk, it's very slow to access. And you may have a pruned node. A pruned node throws away all blocks. So if you need any information that is in an old block, then things get really, really, really slow because either you just can't get the information or you'd have to download the block again and then get it. So those details matter. And one of the things that I think need to be done when you're working on it or you're having other people work on it or you're hoping other people work on it…

Ruben Somsen There is a pseudonym.

Sjors Provoost Is benchmarking.

Ruben Somsen Yeah.

Sjors Provoost And this benchmarking basically could do things like, okay, we could, you know, change the proposal and do a little bit more signature verifications or we could change the proposal in some other way, which means we need to do more disk reading. And now let's try on the Raspberry Pi, you know, with the real blockchain, what performs better, what performs worse. Yeah, that sort of stuff.

Aaron van Wirdum Is this a good time to get into the comparison with the earlier proposals? Yeah. Yeah. Okay, so how does this compare to earlier proposals?

Ruben Somsen Um, yeah, sure. Um So the the original stealth address proposal by uh Peter Todd that one um basically it's quite similar but the thing that was different is that because the scanning requirement was seen as something that was too much effort. So instead of taking the key from the input, the idea was that when you generate a payment, you add an OP_RETURN to it. And in the OP_RETURN, you add a key. And then that is the key that is being used. And the downside of this...

Aaron van Wirdum Yeah, so in that case... The sender's key, in your proposal, the sender's key is actually just the Bitcoin key, the one you're using to send money from. In this earlier proposal by Peter Todd, there's sort of a special key that's not the same key as the one that's used to spend money from, right? And that's included in an OP_RETURN, a bit of extra data in the transaction.

Ruben Somsen Yeah. And so when you do that, obviously, you add more overhead because now you have an OP_RETURN. And the upside from the recipient side, well, it's sort of a half upside because one of the upsides is you still have to scan every transaction, but now you only have to scan every transaction with an OP_RETURN attached to it.

Sjors Provoost And you only have to look at that OP_RETURN.

Ruben Somsen Yes.

Sjors Provoost It's a lot less math than you need to do in your proposal.

Ruben Somsen Yeah, and the database lookups and stuff are easier too because you don't have to kind of go back and find the input. It's right there in one of the outputs. So it's sort of an in-between solution that never really... got popular and I think even the BIP itself was never finished, um and I

Aaron van Wirdum Yeah, yeah I guess one of the downsides is it makes transactions bigger because now you've got to include an OP_RETURN so you know blocks fill up faster if a lot of people do that and fees go up. Yeah.

Sjors Provoost There's also a privacy downside.

Aaron van Wirdum Yeah, it's sort of an indicator that it might be a stealth payment, right? [unclear] Even though you're not sure, but if it's an indecipherable OP_RETURN, then that seems kind of likely.

Sjors Provoost Well, it also means that other people looking at the blockchain can see how many friends you have. Well, friends, quote unquote. So because the number of OP_RETURNs to your stealth address… that's publicly known you know people can take can just count them or is it not? But that's only a BIP 47.

Ruben Somsen Yeah, yeah, you're you're you're confusing it too now. Yeah, okay, no no, so that that's not quite true. Um it is sort of a general you see a bunch of transactions without returns and those are all stealth payments but you don't know who those payments are going to. And the recipients have to check all those specific addresses. So it's sort of an in-between solution where you could say it's sort of like my proposal, but instead there's a tag that says, okay, this is a stealth payment, right?

Aaron van Wirdum Well, this might be a stealth payment.

Ruben Somsen Yeah. Well, I think it's quite obvious, unfortunately.

Sjors Provoost Okay, so the OP_RETURN is only indicating that it's a stealth payment and then after the OP_RETURN is the shared key?

Ruben Somsen Yes.

Sjors Provoost Okay. So in that case, you could probably do that with just... combining signatures, and then you're pretty much back to your proposal, right? Instead of using OP_RETURN, you would just basically use some sort of added, I don't know, added key or tweaked key, and you just have to check every key.

Ruben Somsen Yeah, yeah, so there's a there's a lot of similarity and I I think the uh the stealth address proposal also had the suggestion of adding sort of yet another identifier of saying like okay well instead of checking every OP_RETURN we we mark it where let's say you know you pick a number between let's say zero and and 64 or something and so my stealth payment is let's say 64 exactly so whenever in the OP_RETURN it says number 64 and then there's a public key I only check those so it reduces the anonymity set even further but it also lowers the scanning requirements.

Sjors Provoost Yeah, exactly. Your proposal is a lot of work, but a stealth transaction will look exactly the same as any other transaction.

Aaron van Wirdum Yeah. Okay. And then there's, what is it? BIP 47?

Ruben Somsen That is correct.

Sjors Provoost And that uses the concept of a handshake, I would say. So you publish your stealth address or whatever it is, I think. They use a PayNym as a term?

Ruben Somsen That is a term that Samourai Wallet uses. And I think Sparrow Wallet has it implemented as well. But that is, you know, that's just the implementation. In principle, it's BIP 47.

Sjors Provoost Yeah. So you publish this potentially public key. And then when you want to send somebody money using that, you do an announcement transaction first. So you send somebody a simple, you send around a simple, I think you send a OP_RETURN payment to that address. Yeah. Something like that that's correct and that all that OP_RETURN and address and that OP_RETURN then includes some sort of key uh that the recipient now knows okay I now have a new friend and I need to start monitoring the following addresses so in this case from one single transaction you as the recipient can now generate a whole set of addresses that you just monitor as if you got an xpub yeah right and so that's nice the downside is in this case of what I said before incorrectly for the other one is now everybody can see how many friends you have.

Ruben Somsen Yeah.

Sjors Provoost Because at this handshake address is going to be a bunch of OP_RETURN transactions to that address. So you can count, you know, a maximum of the number of friends you have. I guess somebody could pretend that they're like five people.

Aaron van Wirdum Right.

Sjors Provoost And it adds a little bit of bloat to the blockchain.

Aaron van Wirdum Yeah, so that seems to be the biggest trade-off. Is that right? So your proposal, Ruben, doesn't add any extra data to the blockchain. And then the trade-off is that the recipient has to do quite a bit of work because it has to check all the transactions. While the other proposals in their own ways, they... add more data to the blockchain but then it is easier after you've done that and then there's more nuances but this is…

Ruben Somsen Yeah yeah, well, with the stealth addresses there's still a lot of work to do so I think the stealth [unclear] are sort of just old and outdated and I think you can just sort of leave those aside but for BIP 47 specifically um yes there is not the scanning requirement so so what you said is correct uh for BIP 47 but uh to add a little bit to the downsides um so it is also in you know when you create this notification transaction you're also spending one of your outputs to create that notification. And then those outputs that you're using can then not be used for regular payments if you want to stay anonymous. So it's sort of like you have to sort of the money that you use to create the notifications need to be kept completely separate from the money that you use to pay people. And that is in general very difficult for wallets to implement. And a lot of wallets haven't implemented this correctly. And so there's a lot of potential there for sort of privacy leaking, unfortunately.

Sjors Provoost Right. So you think you have a stealth address, you think you're sending anonymously, but actually because of that announcement, somebody else could just still see exactly… both from the sender side, they can just see that the sender was doing this, but also it means the recipient loses anonymity because if the sender screw up, you can tell the recipient received this many coins because of this correlation. So that's a risk.

Ruben Somsen But one thing that's maybe interesting to note is that in Prague, I had a discussion with a couple of other developers, namely Martin and Alekos. And we have thought of an idea to make BIP47 better and make it so that the notification transaction can be outsourced to someone else. So there's maybe a way to mitigate that for BIP47. And then the only downside that you are left with is the fact that it uses additional on-chain space. And other than that, it functions. So that would uh that would sort of make the comparison a little bit more favorable uh in in in term in terms of comparing into uh comparing silent payments with BIP 47 but still there is sort of this uh this difference in on-chain space usage which is particularly problematic for single payments when you want to send a one-time donation to someone then you know that overhead of that notification is is quite significant.

Sjors Provoost It might be useful also to compare to some other generic schemes to solve the same problem. So one is that instead of publishing... Well, one is that it requires a little bit of interaction. Somebody has to send you an email anonymously and you reply with an xpub and now they can just send whatever they want to that xpub. That's one thing you can do. You can run a little Tor hidden service that will just hand out xpubs to anybody who asks. That is a problem with denial of service and of course you have to run the server. Denial of service means basically somebody could ask you for an xpub. And then ask you for an xpub and ask you for an xpub. And then for every time you've given out an xpub, you've got to monitor like a thousand addresses forever. So that's one thing. Another obvious thing you can do is use Lightning because with Lightning, you have a public key and something like a BOLT 12 tattoo once that's finalized will make it just very easy to receive money, but that puts a bit more burden on the sender. Definitely not as much burden on the recipient because what you're proposing doesn't sound more difficult than running a Lightning node.

Ruben Somsen Yeah.

Sjors Provoost At least not more resource intense than running a Lightning node.

Aaron van Wirdum Yeah.

Sjors Provoost But for the sender, of course, they have to run a Lightning node.

Ruben Somsen Yeah, it's interactive, essentially, when you use Lightning.

Aaron van Wirdum Yeah, but Ruben just promoted to the base chain, so... Don't kick him back to Lightning. Let him enjoy stay here.

Sjors Provoost And on the base chain, you can run a BTCPay Server or something like that. They'll give out a unique address every time. That's a little bit less of a DDoS problem than xpubs?

Ruben Somsen I mean, you still have to give out a new address, right, for BTCPay Server. I still think it's a problem. I wonder how they solve that problem, actually, because you have the same issue where if you continually ask for addresses.

Sjors Provoost Yeah, but an xpub, you know, represents a thousand addresses. So your problem is a thousand times bigger, but it's the same type of problem.

Ruben Somsen Yeah, yeah, true. And so just to sort of generalize, I think the sort of the trade-offs that you're mentioning here is one of interactivity, where with silent payments, the nice thing is it is just... entirely non-interactive uh but you are absolutely correct that you know given sort of like the the complexity of what you said uh it is possible to solve this with interaction and and that is you know essentially kind of what we started off with with me saying okay well Aaron just gives me a new address every time I want to send a payment to him uh that works too.

Aaron van Wirdum Right, yeah. The whole point is to make this non-interactive. Yeah.

Sjors Provoost I wanted to mention one cool possibility that I saw somebody bring up on one of the threads that related to this, which is the idea of using DNS or the .well-known URL to announce your address. So what you can do is if you run a web server or you have a provider that does that for you, is you could say, well, if somebody types in my email address, then the wallet will just basically know where to look, either in the DNS record or at a specific spot on the web server, and it will get the key there. So then if you have a very smart wallet, I could imagine that I just type somebody's email address and it'll see, oh, is there a... is there a silent payment ID there? Is there a BOLT 12 invoice there? Is there an LNURL thing there? I'll just pick one of those three and I'm going to send the money to it. So from a usage point of view, it's very nice to have these static identifiers.

Ruben Somsen Yeah, I see what you mean. Yeah, that's interesting.

Sjors Provoost And I also have a downside, but that might be solvable. And that is what I would call the Hotel California problem.

Ruben Somsen Okay.

Sjors Provoost Because... Basically, once you've given out this thing, people can keep paying to it forever. And at some point, you might realize, ah, running this extra thing on my node is pretty heavy. I'd like to downgrade. I'd like to stop using this. And I think that can be solved by just putting an expiration date into them. Like saying, okay, don't send coins to me after this block height. That would just be part of the standard. And then you scan a few hundred thousand, or you scan like 10,000 blocks extra just to be sure. But you definitely want to make sure that people can opt out of this stuff. Because with BOLT 12, that's not a problem, right? With Lightning, you still have to ask an invoice. And if the server doesn't respond, you don't send money to it. But with this, if somebody sends you money 50 years from now, your descendants will have to scan the whole blockchain.

Ruben Somsen That is a good point and something I hadn't really thought about, but I agree that it would be nice to support maybe a date at which you stop, well, either you stop using the address or you have to refresh the address as to say like, okay, well now I'm going to accept it for longer.

Sjors Provoost So that's when you combine it with this DNS server system, your wallet would just ask again and you could have very short expiration dates even on them, but that's not necessarily the case but you could you could use the same payment code again you could just say like okay I'm only going to guarantee this thing for like a week and then if you ask again next week I'll say okay no don't worry you can use the same key it's going to be valid for another week yeah something like that. I mean, I have a whole bunch of implementation stuff, but I don't think we have to get there.

Ruben Somsen That's interesting, though.

Aaron van Wirdum How long have we been recording?

Sjors Provoost 33 minutes.

Aaron van Wirdum How deep are we into this stuff? Because there's a lot more in the show notes, or at least there's some more in the show notes. Do we want to get into that?

Sjors Provoost I've covered everything I wanted to cover, but...

Ruben Somsen Yeah, I guess the one thing...

Aaron van Wirdum Well, go on, Ruben.

Ruben Somsen Yeah, just one thing I wanted to mention maybe is that I think what's good to point out here is that the scanning downside really is mainly a downside if you're not running a full node. If you're running a full node, the way I look at it is that, well, we still have to kind of get these benchmarks. And so as Sjors already mentioned, there's a pseudonym called the W0XLT, who I'm trying to sort of collaborate with a little bit now uh in order to uh sort of get these benchmarks and he's already created an implementation and once we have those we can get a better idea but like my my feeling is that we can get it down to a level where if you're running a full node and you're at you're doing this additional computation to receive these these silent payments it is not a lot of extra overhead um so from that perspective I think you could say that sort of the overhead is practically zero if you're already running a full node And then for light clients, the problem is that even though like many of the light clients, most of the light clients we have today, they share an xpub with whatever server is running the light client for them. And if you give out your xpub to a server, you lose all your privacy. So it's actually very difficult to have a light client and have privacy at the same time. It's not impossible. We have BIP 157 and 158. Uh that is uh compact block filters so you could have sort of a light client that uh preserves your private privacy better but as far as I Wasabi it's maybe Wasabi wallets and I'm not even sure some Lightning wallets maybe use it but other than that most wallets don't really do that today so my argument there is sort of that if you care about privacy you already sort of have to run a full node

Aaron van Wirdum And so you mentioned there's a pseudonym working on this. So how concrete is this? When am I going to be able to use this?

Sjors Provoost Well, I did run the demo today on signet.

Ruben Somsen Cool, talk about it.

Sjors Provoost So that was fun. Yeah, so the pseudonym you talked about, let's call him Ox.

Ruben Somsen Ox, yeah, it's easier.

Sjors Provoost Created a pull request on Bitcoin Core that is like really marked as like this is just a proof of concept. Don't merge this. Don't even use this with real coins, right?

Ruben Somsen Yeah.

Sjors Provoost And it allows you to create a wallet that can receive silent payments and it allows you to use any wallet really to send silent payments. And, you know, it requires a little bit of manual stuff. But it worked. I mean, at least it seemed to work. I haven't checked if the math actually worked. If somebody steals my signet coins, I don't care for real coins. I want to be a little bit more sure that this is right. I have some remarks in mind that I'll probably post before the show comes out.

Ruben Somsen Excellent.

Sjors Provoost I mean, there are different approaches to get a new proposal like this done, right? And I would congratulate you. I think this is the first time or the fastest ever that you've gone from proposing something really complicated to something that actually demos the concept. And I personally, I like running code to understand something better. And then when I looked at it... Like this approach of changing Bitcoin Core to support it is one approach. Another approach could be something like what Spectre Wallet does is you create a tool that people download or install that is separate from Bitcoin Core, but that uses Bitcoin Core wherever it's useful. And so I looked at both possibilities and both are not trivial in this case. For details, I don't think we necessarily have to go into. Agreed. But this proposal, I don't think this pull request will ever, well, will not get merged in the short run.

Ruben Somsen Yeah.

Sjors Provoost Even if he improves everything.

Aaron van Wirdum Not in Bitcoin Core.

Sjors Provoost No. And a couple of reasons for that is because it essentially requires another index, which takes up space. And it is, you know, like you said, it's maybe not the worst extra performance downside, but it's still pretty significant. You know, it still adds. I think Bitcoin Core would not very quickly commit to a feature that it has to maintain forever that really eats a lot of resources and may screw with other proposals that might enhance scaling. Like how does this combine with AssumeUTXO or how does this combine with Utreexo? So that's why I think it's better to go for a separate tool. On the other hand, any demo that works, I'm happy with it. I don't really care how it's done, whether... whether the demo is a modified version of Bitcoin Core or a little Python script. I don't think it matters as long as people play with the demo because standards will get much better when people actually try them. Otherwise, you get things like BIP32 and... Like, oh, gap limits. Yeah, I guess we should have thought about that before we defined the standard. So yeah, I'm happy to see that. I just would want to caution the listener and it's probably going to take a while.

Ruben Somsen Yeah, I agree with that.

Sjors Provoost Because I guess I should explain the other side of it. If you make a separate tool, now you're no longer a first-class citizen of Bitcoin Core. So you have to communicate through Bitcoin Core through the RPC and it has very limited features, very limited things you can do. And one of the things you may want to do is very tightly integrate with block validation. So when a block comes in, you want to do some processing specifically for the wallet. You can't do that right now with Bitcoin RPC. So yeah, it's tricky.

Ruben Somsen Yeah, there's some complexity there. But yeah, at a high level, I agree with you. And so one of the things that sort of... tricky for me is that actually um spacechains is sort of the project that I'm currently focused on and now this the silent payment thing it was supposed to be sort of a side project where I thought like okay I'm just gonna put this out on a you know in a gist and then I'm done with it and then you know people start running with it and and this Ox guy he implements it and now I'm like okay I gotta you know put some uh some effort into this as well now so I'm being pulled into multiple directions but it's a good thing because it's it's a success story I guess.

Aaron van Wirdum Yeah. I mean, spacechains is literally a side project, right?

Ruben Somsen It's a side chain project. Yes.

Aaron van Wirdum That's the pun of the week.

Ruben Somsen All right.

Sjors Provoost It's a good pun. I have another pun on the GitHub comment, but it's not for here.

Ruben Somsen All right. Well, I'll look forward to hearing that offline then.

Aaron van Wirdum I cannot wait, Sjors, to read that.

Sjors Provoost It's going to be amazing. Okay. I think that covers everything.

Ruben Somsen Yeah.

Sjors Provoost Is there anything, Aaron?

Ruben Somsen I think there's something you wanted to bring up still, or am I mistaken here?

Aaron van Wirdum I mean, I was going to ask about CoinJoin.

Ruben Somsen Oh, yes, of course.

Aaron van Wirdum That seems like opening up another can of worms. I don't know if we want to go there.

Ruben Somsen That is true.

Aaron van Wirdum Now that I've brought it up, we can't really ignore it completely. Do you want to summarize this in like a minute?

Sjors Provoost I think we should briefly look at the worms.

Ruben Somsen Yeah, I agree. Now, that's actually a good one to point out. So I think this is one of these things that I feel most uncomfortable with in terms of... like because what you ideally what you want to do is you want this protocol to not get in in the way of how people do transactions and so far the way we've described it it sort of works really well if there is one sender if I create the transaction but what if we wanted to create a transaction as a CoinJoin where we have multiple people adding their inputs um and so So the first issue is that you sort of have two variants of...

Sjors Provoost And then one of the recipients is a stealth address.

Ruben Somsen Yeah, exactly. Yes. Yes. That's good. Good to add. Yeah. Thank you. So the first issue is sort of that you have, you have two variants that you could, could do for a silent payments. Well, there are more variants, but these are the two sort of main ones, which is either you pick one, one input and you use that to generate the shared secrets, or you pick the combination of all the inputs. And this is particularly relevant with CoinJoins, because if you pick just one input, then what that means is that if someone pays you in a CoinJoin, then the recipient normally doesn't know what your input was. So that's actually very good for privacy. But if you use the silent payments, now if it's just with a single input, you can see which input was paying you. And so that leaks some privacy for the sender.

Aaron van Wirdum Yeah, you can see which input pays you because that's the one that adds up to your new address. Exactly. There's only one input that matches your new address. Yes.

Ruben Somsen And so that's solvable by saying, okay, well, we pick all the inputs instead. And we add those inputs together and we use that to generate the shared secret. But once you do that, you need the collaboration of all the CoinJoin participants. And in fact, you need them to generate a shared secret. And you also don't want them to know who you are paying. So you need to get them to give you their shared secret in a way that they don't know what they're giving to you. And there's a protocol for that too, which is basically a blind way of doing a Diffie-Hellman, which is also used in e-cash. Long story short, a lot of complexity.

Aaron van Wirdum A lot of worms.

Sjors Provoost Yeah, and you're actually making the single— the simple case, you're making that more complicated by aggregating the signatures because normally when I use a wallet to make the silent payment, I just need to pick one coin, one input. And then if the wallet needs to, it can just add more inputs to that transaction and it will still work. But if you want to have all the inputs count towards the shared key, then I need to decide before I have the set destination address, I need to decide which coins I'm going to use. And so then you have the coin selection process separate from the payment process and that, at least in Bitcoin Core, that's going to give you another can of worms that I recommend not opening.

Ruben Somsen Yeah.

Sjors Provoost There are solutions to it.

Ruben Somsen Yeah. Well, the other thing that's sort of nice about adding all the input keys together and why I sort of gravitate towards that is that it essentially cuts down the scanning requirement in half. Because now, instead of having to scan every individual input, you can scan the aggregation of all the inputs. And on average, the transaction has two inputs.

Sjors Provoost That's true, but that's where the benchmarking has to come in. Because I would not be surprised at all whether you look at inputs individually or you add them up. Most of the work is probably going to be in fetching the original transactions from some disk somewhere. And then the actual elliptic curve math is going to be much less than that. Because in general, it takes a long time to read something from a disk. It takes a very short time to do a calculation on the CPU. But that could be completely wrong. That's why you want to benchmark this stuff.

Ruben Somsen I am sort of I have the same concern in terms of this needs to be benchmarked and we need to compare it all and quite frankly I I even think that maybe the UTXO set scanning is overkill too and maybe it's just better to just do the the entire scanning when you do IBD and maybe that's sufficient um so it's sort of uh yeah it all comes down to the benchmarks, basically. I agree with that.

Aaron van Wirdum Cool. Okay. I think that's our episode. Sjors, what do you think?

Sjors Provoost Sounds good. I'm not going to put this thing as a tattoo on me yet, but I'm going to keep it in mind. Yep, I think that's it. So thank you for listening to Bitcoin.

Aaron van Wirdum Explained.