WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:20.620 --> 00:00:22.820 Live from Utrecht, this is Bitcoin 00:00:22.820 --> 00:00:23.940 Explained. 00:00:24.120 --> 00:00:24.460 Hey Sjors. 00:00:24.860 --> 00:00:25.020 Hello. 00:00:26.280 --> 00:00:30.820 So Sjors, today we're going to talk about partially signed Bitcoin transactions. 00:00:31.120 --> 00:00:31.480 That's right. 00:00:32.180 --> 00:00:37.830 AKA PSBTs. Now, our dear avid listener. 00:00:38.390 --> 00:00:43.270 As you probably, as you certainly know, we've already discussed this in probably 00:00:43.270 --> 00:00:49.210 at least one or two, maybe even three episodes previously. But every time that 00:00:49.210 --> 00:00:53.950 it came up, it was sort of in context of some other topic, like the actual topic 00:00:53.950 --> 00:00:59.250 we were discussing. And we didn't really make any episode specifically about 00:00:59.250 --> 00:01:04.940 partially signed Bitcoin transactions. So Sjors and I decided we should have an 00:01:04.940 --> 00:01:07.880 episode that's really about partially signed Bitcoin transactions. 00:01:08.200 --> 00:01:08.760 That's right. 00:01:09.720 --> 00:01:14.720 I'm just sort of prefacing that because if you've heard us explain it in previous 00:01:14.720 --> 00:01:19.240 transactions, you know, we won't blame you if you want to skip this episode. 00:01:19.340 --> 00:01:21.720 We'll still be your friend. Isn't that right, Sjors? 00:01:21.920 --> 00:01:23.620 No, I think you should just listen to it. 00:01:25.790 --> 00:01:30.550 Sjors, Sjors and I don't always see eye to eye. Let's just get to our favorite 00:01:30.550 --> 00:01:31.430 part of the episode. 00:01:31.690 --> 00:01:32.090 That's right. 00:01:32.670 --> 00:01:37.250 Sjors stacks sats, Sjors stacks sats, Sjors stacks sats. 00:01:37.590 --> 00:01:41.130 Yeah. This is why you really wanted to have video because it's quite funny, but 00:01:41.130 --> 00:01:46.430 I'll read two. One is from Eric 99 who says, stay humble stack sats. 00:01:47.190 --> 00:01:53.020 And for 50,000 satoshis. and another one that's funny I think from 00:01:53.020 --> 00:01:57.960 at vague 10 000 satoshis with this podcast has encrypted my heart. 00:01:57.960 --> 00:01:59.560 Oh, that's so sweet. 00:01:59.560 --> 00:02:03.490 And that's a reference to the last episode to the peer-to-peer encryption 00:02:03.490 --> 00:02:04.010 episode. 00:02:04.010 --> 00:02:09.410 Sjors, if people want their boostagrams read out loud in Bitcoin Explained and 00:02:09.410 --> 00:02:13.650 pay you the sweet sats, what do they need to do where do they where do they go? 00:02:13.650 --> 00:02:19.140 Oh, they need to google something like value for value or boostagrams and install 00:02:19.140 --> 00:02:24.220 one of these modern podcasting 2.0 apps that allow you to stream sats per minute. 00:02:24.220 --> 00:02:28.800 And also, if you like, do a shout out. There's no guarantee that I'll read it. 00:02:29.360 --> 00:02:34.330 So that was Sjors Stacks Sats. Back to the episode. 00:02:35.260 --> 00:02:40.760 Sjors, partially signed Bitcoin transactions. First of all, is this one of the 00:02:40.760 --> 00:02:45.620 parts of Bitcoin that you've contributed to actively? Is that right? 00:02:46.460 --> 00:02:49.440 I've definitely done testing of it, a little bit of review. 00:02:49.600 --> 00:02:53.900 Because you've done a lot of work on hardware wallets integration, and I think 00:02:53.900 --> 00:02:55.820 that probably has something to do with this. 00:02:55.820 --> 00:03:00.020 That definitely uses PSBTs a lot, so I've definitely seen a lot of them, but I 00:03:00.020 --> 00:03:01.220 don't write this particular code. 00:03:02.060 --> 00:03:07.860 okay so let's as always start at the beginning what is 00:03:07.860 --> 00:03:13.820 what what before there were partially signed Bitcoin transactions before this 00:03:13.820 --> 00:03:19.690 existed Usually we start with the one sentence explanation of what it is. So 00:03:19.690 --> 00:03:23.450 can you give us a one sentence explanation of what PSBTs are? 00:03:23.810 --> 00:03:28.130 Yeah, it's basically a file that contains a draft transaction or even a complete 00:03:28.130 --> 00:03:33.170 transaction and some extra information about the transaction. So the partially 00:03:33.170 --> 00:03:36.370 signed stands for that it might not be signed at all or it might have one 00:03:36.370 --> 00:03:40.410 signature if it's a multisig out of five, etc. So it's a place where you collect 00:03:40.410 --> 00:03:41.590 all the components for a transaction. 00:03:42.030 --> 00:03:46.770 Okay. so that's the one sentence explanation now let's go to the beginning so 00:03:46.770 --> 00:03:52.570 before this existed what was the problem why did someone think 00:03:52.570 --> 00:03:53.910 that this needed to exist? 00:03:53.910 --> 00:03:58.370 Well, the problem is when you're trying to do anything other than just creating a 00:03:58.370 --> 00:04:01.350 simple transaction where you know you have a wallet you're sending coins 00:04:01.350 --> 00:04:05.230 somewhere and your wallet just makes a transaction signs it and it's done if you 00:04:05.230 --> 00:04:08.900 want to do something more complicated like signing offline or if you want to use 00:04:08.900 --> 00:04:13.180 a hardware wallet, maybe especially one that's somewhere else, or if you wanted 00:04:13.180 --> 00:04:16.700 to do a multisig transaction, when we talked about multisig in earlier episodes, 00:04:17.420 --> 00:04:22.540 then things became more complicated. You'd have to somehow ferry that transaction 00:04:22.540 --> 00:04:26.340 around and make sure that all the other devices know what they need to do. And 00:04:26.340 --> 00:04:28.240 there was only ad hoc solutions to that. 00:04:29.990 --> 00:04:35.740 Hang on. Okay. So the key thing here is that sometimes 00:04:35.740 --> 00:04:40.980 a Bitcoin transaction consists of you know, data, 00:04:41.340 --> 00:04:44.840 inputs, signatures, outputs. 00:04:45.320 --> 00:04:50.320 Well, that's the point though. So sometimes you want to create a signature on a 00:04:50.320 --> 00:04:54.500 different device than you created the rest of the transaction with, right? 00:04:54.760 --> 00:04:55.080 Yes. 00:04:55.300 --> 00:04:58.720 And this was already possible even before PSBTs. 00:04:58.920 --> 00:04:59.440 Yes, it was. 00:04:59.540 --> 00:05:04.850 Like Electrum already allowed this and I think even Bitcoin Core 00:05:04.850 --> 00:05:10.230 allowed this kind of stuff, but they did it in different ways. 00:05:11.120 --> 00:05:14.880 Yeah, and it was a fairly ad hoc. Yeah, basically it was ad hoc. Yeah, and it was 00:05:14.880 --> 00:05:19.800 not very flexible. So, for example, Bitcoin would create a transaction that would 00:05:19.800 --> 00:05:23.120 just... I think it would just set all the signatures to zero. And then your other 00:05:23.120 --> 00:05:25.440 wallet software would just have to guess what it has to do. 00:05:27.820 --> 00:05:30.240 You said Bitcoin. I think you mean Bitcoin Core then? 00:05:30.400 --> 00:05:30.680 Yes. 00:05:30.940 --> 00:05:31.060 Right. 00:05:32.700 --> 00:05:37.930 Okay, but that... I mean, that would still work if you use Bitcoin Core, right? 00:05:38.130 --> 00:05:42.530 So it's only a problem, I would guess, if you want to create a transaction on 00:05:42.530 --> 00:05:46.350 Bitcoin Core and then sign it with Electrum or something like that. Or if you 00:05:46.350 --> 00:05:50.430 want to create a multisig and one person is using Bitcoin Core, someone else is 00:05:50.430 --> 00:05:54.510 using Electrum, someone else is using whatever wallet they're using. That's when 00:05:54.510 --> 00:05:56.250 it becomes a problem. Is that right? 00:05:56.450 --> 00:05:59.970 I think it also becomes a problem if you want to use a wallet that's offline and 00:05:59.970 --> 00:06:05.060 not caught up to the most recent blockchain. So because if you're not up to date 00:06:05.060 --> 00:06:09.400 to the use blockchain, you don't necessarily know how to sign something because 00:06:09.400 --> 00:06:13.880 the transaction itself, when you receive it, it has inputs and those inputs refer 00:06:13.880 --> 00:06:17.640 to previous outputs. and you don't have those previous outputs unless your 00:06:17.640 --> 00:06:20.940 blockchain is up to date so if you have some deep cold storage and you don't want 00:06:20.940 --> 00:06:23.120 to sync it to the blockchain it was this is also quite annoying. 00:06:23.120 --> 00:06:28.140 Okay, so that's that's and we did discuss this in a previous episode I remember I 00:06:28.140 --> 00:06:32.640 don't remember what episode but this also so this so there are several issues 00:06:32.640 --> 00:06:34.260 where it 00:06:35.990 --> 00:06:41.810 could be an issue that there wasn't a unified protocol for figuring out this kind 00:06:41.810 --> 00:06:45.290 of stuff. That's the core of that problem, right? Originally… 00:06:45.530 --> 00:06:49.610 So there's another thing that is difficult to do. So it really depends on how 00:06:49.610 --> 00:06:55.510 your wallet is set up. If you have your copy of Bitcoin Core somewhere else in an 00:06:55.510 --> 00:06:59.890 offline place, but that has the same wallet as you do, then the following problem 00:06:59.890 --> 00:07:02.930 is not a problem. But one of the things you want to do is you want to check that 00:07:02.930 --> 00:07:06.510 your change address is actually real. So if we're doing a transaction together, 00:07:06.690 --> 00:07:11.890 for example, I might say we might have a shared wallet of 10 Bitcoin and we want 00:07:11.890 --> 00:07:15.950 to send one Bitcoin somewhere. Then I'll show you a transaction. Hey, just sign 00:07:15.950 --> 00:07:21.390 this part and it'll show one Bitcoin and nine Bitcoin. And then 00:07:21.390 --> 00:07:26.310 the problem is that you don't know that the original amount is 10 Bitcoin. Like I 00:07:26.310 --> 00:07:29.170 might tell you that that is the case, but in order for you to check that, you 00:07:29.170 --> 00:07:31.390 need to know a few other things about the wallet. 00:07:33.240 --> 00:07:37.760 You know what? I think this is the very first episode we ever made is what we 00:07:37.760 --> 00:07:40.560 discussed, what you're mentioning right now. 00:07:41.140 --> 00:07:45.540 Yeah, exactly. In the first episode, we described some attacks related to change 00:07:45.540 --> 00:07:48.380 addresses. So I guess there's two different things. I wasn't super clear there. 00:07:48.820 --> 00:07:51.920 One is that you want to know that the change address that's listed in a 00:07:51.920 --> 00:07:57.000 transaction is actually yours. So Bitcoin Core can easily check that. It sees an 00:07:57.000 --> 00:08:00.800 address. It just checks out its 3,000 addresses that it has in memory and says, 00:08:00.900 --> 00:08:05.160 okay, this is one of mine. So anything that goes there has really change. The 00:08:05.160 --> 00:08:08.340 other is that you want to make sure that the total amount that you're spending... 00:08:08.990 --> 00:08:12.830 so in this case one Bitcoin goes somewhere nine Bitcoin is change that that is 00:08:12.830 --> 00:08:17.270 actually the total amount that you're spending so I could trick you and and spend 00:08:17.270 --> 00:08:21.990 a 20 Bitcoin coin and have one Bitcoin going somewhere nine Bitcoin being change 00:08:21.990 --> 00:08:27.240 and then 10 Bitcoin going to some miner that I'm collaborating with and in order 00:08:27.240 --> 00:08:30.380 to prevent that you need to have the previous output so basically there's a bunch 00:08:30.380 --> 00:08:32.300 of information that you want to know for your own safety. 00:08:34.380 --> 00:08:39.260 All right I've now heard a lot of things and I want to I want to move on to the 00:08:39.260 --> 00:08:44.920 next part of this podcast but also I want to make sure that this part was clear 00:08:45.300 --> 00:08:50.600 so to reiterate even before 00:08:50.600 --> 00:08:56.530 PSBTs you could sort of create transactions and sign them 00:08:56.530 --> 00:09:00.010 somewhere else it was already possible but there were a number of problems with 00:09:00.010 --> 00:09:04.770 that one is you're using different wallets to create the transaction and to sign 00:09:04.770 --> 00:09:09.540 it that was a problem another one is multisig where different wallets want to 00:09:09.540 --> 00:09:15.420 sign it in a different way and then the third is there are a couple of attacks is 00:09:15.420 --> 00:09:19.400 that the best way to sort of bucket that one there's a couple of attacks and it 00:09:19.400 --> 00:09:23.260 has to do with change addresses it has to do with previous 00:09:23.740 --> 00:09:29.520 transactions and you not knowing how much money was involved so 00:09:29.520 --> 00:09:30.740 overpaying fees. 00:09:30.740 --> 00:09:31.680 Yep, exactly. 00:09:31.680 --> 00:09:36.400 Okay, how about we just cut it there so we got… 00:09:36.860 --> 00:09:37.280 Yeah. 00:09:37.540 --> 00:09:40.060 The third bucket is all kinds of attacks. 00:09:40.420 --> 00:09:40.820 Yeah. 00:09:41.300 --> 00:09:42.400 Simple. All right. 00:09:43.870 --> 00:09:49.670 So at some point, someone thought we need to improve this. Who was this when? 00:09:50.430 --> 00:09:53.510 Well, many people probably thought it, but Andrew Chow actually wrote the 00:09:53.510 --> 00:09:56.750 standard called PSBT in 2017, I think. 00:09:56.970 --> 00:10:00.210 Okay, he started in 2017 and it's done now? 00:10:01.230 --> 00:10:03.130 Yeah, it's been done for many years. 00:10:03.450 --> 00:10:08.010 I guess you can always upgrade it or update it. Does that happen or is it kind of 00:10:08.010 --> 00:10:08.430 just done? 00:10:08.590 --> 00:10:12.890 No, there is a version 2 for PSBT, which came out a few years ago, but it's only 00:10:12.890 --> 00:10:18.310 a very small change. So generally with PSBT, it's pretty flexible, so we can 00:10:18.310 --> 00:10:19.210 explain how it works. 00:10:20.190 --> 00:10:24.990 Yeah, how does it work, Sjors? So what is PSBT like concretely? What does it do? 00:10:25.250 --> 00:10:29.270 Yeah, it's a bit boring. It's just a file. And the file contains the information 00:10:29.270 --> 00:10:33.990 you need for a transaction. You could say the ingredients for a transaction. So 00:10:33.990 --> 00:10:39.510 it contains the inputs that you're trying to spend. It creates the outputs that 00:10:39.510 --> 00:10:45.400 you want to send to. It contains signatures. And, you know, 00:10:45.520 --> 00:10:48.240 normally in a Bitcoin transaction, the signatures are right inside the input, but 00:10:48.240 --> 00:10:50.520 here you would neatly separate all this stuff. 00:10:50.700 --> 00:10:51.820 Well, they're in the witness, right? 00:10:53.060 --> 00:10:55.000 Yeah, or depends on if it's SegWit or not. 00:10:55.660 --> 00:10:58.820 Okay, does PSBT do both? Does it do non-SegWit? Okay. 00:10:59.280 --> 00:11:02.420 Yeah, but the signatures are basically in a separate place or the witnesses are 00:11:02.420 --> 00:11:05.960 in a separate place. The same with Taproot. I think it has its own place for 00:11:05.960 --> 00:11:11.530 these things. But you can also put more in it. For example, you can put an xpub 00:11:11.530 --> 00:11:15.170 in it, and this xpub can help the other wallet figure out which addresses it 00:11:15.170 --> 00:11:20.330 owns. You can put BIP32 derivation paths in it, so you can see, okay, if I have 00:11:20.330 --> 00:11:25.550 my wallet seed, what derivations do I do to actually get this change address, for 00:11:25.550 --> 00:11:30.290 example, so that you can check that it's your own address. There can be Taproot 00:11:30.290 --> 00:11:34.370 -specific things, so if you have multiple different possible scripts, you can... 00:11:34.580 --> 00:11:36.180 You can provide the script in there. 00:11:36.400 --> 00:11:41.500 Right. So here's how I would imagine this. And just correct me if this is too 00:11:41.500 --> 00:11:47.360 simple. So it sounds like you're basically creating a file 00:11:47.360 --> 00:11:53.240 which has fields which are dedicated for put the inputs in this field, put the 00:11:53.240 --> 00:11:57.680 outputs in this field, put the signatures in this field, and so forth. 00:11:57.840 --> 00:11:58.300 That's right. 00:11:59.220 --> 00:12:02.920 and you don't have to fill them all you can just fill some of them and leave 00:12:02.920 --> 00:12:08.360 others open and that's what you would send to whether it's your multisig partner 00:12:08.360 --> 00:12:12.380 or your hardware wallet so you and then you're 00:12:14.670 --> 00:12:18.850 your multisig partner would know, oh, this is a PSBT. So this is how I look at 00:12:18.850 --> 00:12:23.090 this. This is what these fields mean. These are filled out. These are empty. Now 00:12:23.090 --> 00:12:24.110 I know what to do with it. 00:12:24.310 --> 00:12:24.610 Exactly. 00:12:24.850 --> 00:12:25.890 This is basically what it is. 00:12:26.010 --> 00:12:29.050 Yeah. And one of the other things that you can add to it is a previous 00:12:29.050 --> 00:12:32.830 transaction. Right. So in the scenario where you don't know how 00:12:32.830 --> 00:12:38.010 much money you're spending, the trick is to basically put in the previous 00:12:38.010 --> 00:12:42.350 transaction because the previous transaction will say on the output side, what 00:12:42.350 --> 00:12:45.060 the amount is. And therefore the signer can check that. 00:12:45.770 --> 00:12:48.670 And the signer would check that by checking the blockchain essentially? 00:12:49.410 --> 00:12:54.130 No, it would simply check that this transaction that it's spending that this has 00:12:54.130 --> 00:12:57.750 the output. It doesn't necessarily care that this transaction really existed. It 00:12:57.750 --> 00:13:02.080 depends on what you're trying to verify. But in this case, the idea is that you 00:13:02.080 --> 00:13:06.120 can't make a fake transaction. I mean, you could make a fake transaction, but if 00:13:06.120 --> 00:13:09.760 the fake transaction doesn't exist on the blockchain, then you're signing 00:13:09.760 --> 00:13:12.680 something that is spending a transaction that does not exist on the blockchain. 00:13:12.820 --> 00:13:13.760 And therefore is invalid. 00:13:13.980 --> 00:13:17.000 So it won't get broadcast. So in that sense, you should be fine there. 00:13:17.240 --> 00:13:17.480 Right. 00:13:17.620 --> 00:13:20.880 But it is annoying to have to include the previous transaction. And we talked in 00:13:20.880 --> 00:13:25.420 earlier episodes that SegWit reduced the need to include this previous 00:13:25.420 --> 00:13:29.880 transaction, but there was a bug in SegWit. And so you still kind of have to 00:13:29.880 --> 00:13:33.480 include the previous transaction and with Taproot hopefully you don't have to 00:13:33.480 --> 00:13:36.220 include the previous transaction because you actually know what the amount is 00:13:36.220 --> 00:13:39.300 without having to check the previous transaction so that's nice. 00:13:39.300 --> 00:13:44.880 Okay, so just to sort of contextualize this the PSBT it's not 00:13:44.880 --> 00:13:49.680 a consensus rule it's not it's not even part of the Bitcoin consensus or Bitcoin 00:13:49.680 --> 00:13:53.820 protocol at all. No, I guess depending what you want to call part of the Bitcoin 00:13:53.820 --> 00:13:57.960 protocol but it's really a convention that essentially 00:13:59.600 --> 00:14:02.820 wallet developers can use right that's what it comes down to. 00:14:02.820 --> 00:14:07.060 Yeah, it makes wallets more interoperable and makes it easier to do these more 00:14:07.060 --> 00:14:08.460 complicated signings. 00:14:08.460 --> 00:14:13.920 Right, that makes a lot of sense so what wallets use this right now? 00:14:14.150 --> 00:14:19.770 Well, or yeah that's that's actually increasing so I think the first wallet that 00:14:19.770 --> 00:14:25.200 actually ever supported it is the COLDCARD and the way the COLDCARD works is, or 00:14:25.200 --> 00:14:28.460 it has different ways of working, but one way it works is completely separate 00:14:28.460 --> 00:14:33.370 from your computer, air gap, as people would call it. You use Bitcoin Core on 00:14:33.370 --> 00:14:37.250 your computer to create a transaction that has no signatures on it. Then you put 00:14:37.250 --> 00:14:41.850 that on an SD card. You put the SD card in the device. The device signs it, spits 00:14:41.850 --> 00:14:45.950 out the SD card, and you put the SD card back in the computer, and then Bitcoin 00:14:45.950 --> 00:14:50.280 Core reads it, sees the signatures, and sends it. And so this is a nice, that's 00:14:50.280 --> 00:14:54.420 kind of why it fits that model very well. But recently, I believe Ledger also 00:14:54.420 --> 00:15:00.310 added it. And so actual support for it. And one of the things that, I 00:15:00.310 --> 00:15:03.890 think they needed PSBT 2 for this because PSBT 2 made some things easier to 00:15:03.890 --> 00:15:08.130 handle for the device. The problem with these hardware wallets is that they tend 00:15:08.130 --> 00:15:11.870 to have very limited resources. So they cannot, especially in case of the Ledger, 00:15:11.990 --> 00:15:15.400 they can't hold the whole transaction in memory. So if the transaction is very 00:15:15.400 --> 00:15:19.360 big, especially if it has previous transactions that you also want to look at, it 00:15:19.360 --> 00:15:23.640 cannot hold all of it in memory. And so I think they set up a whole ritual where 00:15:23.640 --> 00:15:27.220 the computer would send the first part of the PSBT and then the wallet would 00:15:27.220 --> 00:15:31.680 check it and would ask the computer for the next part of the PSBT or some other 00:15:31.680 --> 00:15:35.790 part, et cetera, and then go through it. One of the other things hardware wallets 00:15:35.790 --> 00:15:38.830 can do with this is, again, because they don't have so much memory, a hardware 00:15:38.830 --> 00:15:43.030 wallet typically doesn't know which addresses it controls. So if you're saying 00:15:43.030 --> 00:15:46.170 here's a change address, if you're doing that on a laptop, you can just check 00:15:46.170 --> 00:15:49.730 your list of 3000 addresses and see that it's a change address. But for a 00:15:49.730 --> 00:15:55.030 hardware wallet, keeping such a long list is not practical. So instead, the PSBT 00:15:55.030 --> 00:15:59.070 says, hey, you know, this is how you derive your own change address. And then the 00:15:59.070 --> 00:16:03.190 hardware wallet will actually do the derivation and say, yep, if I do this from 00:16:03.190 --> 00:16:06.370 a seed, I get this address. And now I know that it's actually a change address. 00:16:07.170 --> 00:16:09.050 So that's kind of what the devices do with it. 00:16:10.370 --> 00:16:14.750 Others that use the device. I don't know of any other hardware wallets, how far 00:16:14.750 --> 00:16:18.870 they are along, but there is a project called HWI, which we have covered in an 00:16:18.870 --> 00:16:21.430 earlier episode, episode 30, I believe. 00:16:21.710 --> 00:16:24.090 Yeah, maybe give a quick recap of what it is. 00:16:24.250 --> 00:16:30.090 Yeah, it's called Hardware Wallet Integration. And what it does is it 00:16:30.090 --> 00:16:34.390 basically is a bridge between Bitcoin Core and a whole bunch of different 00:16:34.390 --> 00:16:40.360 hardware wallets. And that way, Bitcoin Core only needs to speak PSBT as a 00:16:40.360 --> 00:16:45.200 language it can send a PSBT to a device it can receive a PSBT from the device but 00:16:45.200 --> 00:16:51.050 if the device itself doesn't speak PSBT HWI can do the translation for it so then 00:16:51.050 --> 00:16:54.630 it's HWI it's actually taking the PSBT and turning it into whatever obscure 00:16:54.630 --> 00:16:57.230 format the device wants okay 00:16:59.310 --> 00:17:05.010 is there a reason not to just 00:17:05.010 --> 00:17:10.410 speak PSBT other than I haven't had the time to implement it yet are there any 00:17:10.410 --> 00:17:11.250 downsides to it 00:17:11.730 --> 00:17:15.330 Well, I think that's the biggest argument. So wallets haven't had times to 00:17:15.330 --> 00:17:18.490 implement it. My guess is that any wallet that wants to do something fancy and 00:17:18.490 --> 00:17:23.010 new, like say Miniscript, would be wise to just use PSBT because 00:17:23.010 --> 00:17:27.770 just having to figure out yourself how to do these complicated things, it's 00:17:27.770 --> 00:17:30.590 probably easier to just use something that's out there. 00:17:30.930 --> 00:17:36.630 All right. But if you use a hardware wallet with Bitcoin Core, and the hardware 00:17:36.630 --> 00:17:40.370 wallet speaks PSBT then you don't need HWI? 00:17:40.370 --> 00:17:44.390 Well, you kind of still do because other than the format there's other things you 00:17:44.390 --> 00:17:47.750 need to do to communicate to a hardware wallet you need to speak USB for example 00:17:47.750 --> 00:17:52.710 and all the USB stuff that's also something that we don't want to put in Bitcoin 00:17:52.710 --> 00:17:57.230 core because it creates a bunch of dependencies so the HWI will still you know 00:17:57.230 --> 00:18:01.030 know where to find the hardware wallet physically like which port it's on and and 00:18:01.030 --> 00:18:05.180 then talk over USB or some other protocol but it will not have to do any 00:18:05.180 --> 00:18:05.640 translation. 00:18:09.620 --> 00:18:12.420 Are you fluent in USB Sjors? 00:18:12.560 --> 00:18:16.020 I am not. And also the example of the Ledger I just gave you, where the Ledger 00:18:16.020 --> 00:18:21.580 cannot hold the whole PSBT in one, all of it in its memory, then what PSBT does 00:18:21.580 --> 00:18:25.800 is basically helping with the back and forth. So it's able to send part of a PSBT 00:18:25.800 --> 00:18:30.640 that the hardware wallet asks for. Bitcoin Core doesn't know how to do that. So 00:18:30.640 --> 00:18:33.220 there's still a role for HWI or something similar. 00:18:35.060 --> 00:18:39.080 Which I think brings us to the last user that we wanted to briefly talk about. 00:18:41.100 --> 00:18:45.960 Yeah, so there's also... So recently we've seen, 00:18:46.430 --> 00:18:52.230 for example, Bitcoin Magazine has been publishing these inscriptions and these 00:18:52.230 --> 00:18:57.720 Ordinals, which we love because we're contractually 00:18:57.720 --> 00:18:59.820 obligated to love it. Aren't we, Sjors? 00:19:00.040 --> 00:19:03.100 I don't think I'm contractually obligated to love it. I didn't even know they had 00:19:03.100 --> 00:19:04.380 them until like five minutes ago. 00:19:05.080 --> 00:19:08.740 Oh, you didn't know? Yeah, Bitcoin Magazine has been publishing some inscriptions 00:19:08.740 --> 00:19:14.710 and some Ordinals. And it is controversial. Like people are now not coming to the 00:19:14.710 --> 00:19:19.150 conference in Miami. I mean, I don't think a lot of people, but you know, it's 00:19:19.150 --> 00:19:21.430 like a Twitter controversy, you know. 00:19:21.970 --> 00:19:22.270 Okay. 00:19:22.750 --> 00:19:28.560 For the record, Ordinals are still retarded. I agree with that [unclear] as well, 00:19:28.560 --> 00:19:28.980 I think. 00:19:28.980 --> 00:19:32.220 But are they a cancelable offense? That's the question, right? 00:19:32.220 --> 00:19:34.540 Yeah, that is the question I would say probably not. 00:19:34.540 --> 00:19:38.700 Anyway, we we talked about inscriptions especially not so much Ordinals in 00:19:38.700 --> 00:19:43.010 general in an earlier episode so we don't have to repeat that. 00:19:43.010 --> 00:19:48.510 Yeah, and but there is something interesting so there's something interesting 00:19:48.510 --> 00:19:52.830 about the way that Bitcoin Magazine did the sale and I don't think it's unique to 00:19:52.830 --> 00:19:57.010 Bitcoin Magazine but there is something interesting there and it is using 00:19:59.430 --> 00:20:01.490 PSBTs. So it's called a Dutch auction. 00:20:03.160 --> 00:20:06.580 What is a Dutch auction, Sjors? And why is it called a Dutch auction? 00:20:06.760 --> 00:20:08.000 Well, because the Dutch invented it. 00:20:08.610 --> 00:20:11.890 I mean, is this how the tulips are still traded? 00:20:11.950 --> 00:20:17.250 So usually when English people say Dutch something, it's an insult. Dutch courage 00:20:17.250 --> 00:20:20.910 is like if you drink a lot of alcohol and then you have courage. But a Dutch 00:20:20.910 --> 00:20:23.910 auction is actually not an insult. It's actually just the mechanics of an 00:20:23.910 --> 00:20:28.010 auction. The idea is you, as the seller, you start at a high price and you say, 00:20:28.010 --> 00:20:31.910 does anybody want to buy it at this price? And then you go down in price and you 00:20:31.910 --> 00:20:35.180 go down in price until finally somebody... matches your order. 00:20:35.180 --> 00:20:38.980 I mean I think that's still how it works right if you go to like the big auction 00:20:38.980 --> 00:20:42.300 houses for the tulips and stuff like I've never been but I've seen it on 00:20:42.300 --> 00:20:44.920 television I think that's actually how they do it. 00:20:44.920 --> 00:20:48.080 I think so then so then they would have been doing it for about 400 years now, 00:20:48.080 --> 00:20:51.780 so… right, it's a long tradition. so you can use PSBTs for this and apparently 00:20:51.780 --> 00:20:55.360 that's what Bitcoin Magazine did they did a Dutch auction using PSBTs. 00:20:55.360 --> 00:21:01.310 Yeah, so how does that work? What's the idea here? And how do PSBTs come in? 00:21:01.490 --> 00:21:04.650 Yeah, so PSBTs even come in without an auction because there's also websites 00:21:04.650 --> 00:21:08.150 where you can just buy, I think you can buy inscriptions or something like that. 00:21:08.250 --> 00:21:13.970 And they also use PSBTs. So we should explain that mechanism first. The idea is 00:21:13.970 --> 00:21:19.630 that basically you create a PSBT, so a draft transaction essentially, 00:21:19.910 --> 00:21:25.770 that has on the input side, it takes your inscription or 00:21:25.770 --> 00:21:26.410 [unclear], whatever. 00:21:29.340 --> 00:21:34.190 And then on the output side, it's sending a certain amount of money to you. But 00:21:34.190 --> 00:21:37.070 that's not the complete transaction. But that's the only part you care about. 00:21:37.310 --> 00:21:41.870 What you want is to receive a bunch of money. So that's what you're specifying on 00:21:41.870 --> 00:21:46.210 the output. And what you're willing to do for that is to send the inscription 00:21:46.210 --> 00:21:50.920 slash ordinal slash whatever it is anywhere. You don't care where it goes. You 00:21:50.920 --> 00:21:56.020 just care that you get the money. Now, you publish this PSBT on a website or an 00:21:56.020 --> 00:22:00.650 exchange, whatever it is. somebody else can come in and say, hey, I think this is 00:22:00.650 --> 00:22:05.250 a fair price. Let me take this PSBT and add an input, 00:22:05.900 --> 00:22:11.850 namely my money, and add one or two outputs. Maybe you add an output 00:22:11.850 --> 00:22:17.520 for change and an output for where you want the ordinal 00:22:17.520 --> 00:22:22.980 inscription, whatever it is, to go. And then you sign that and you put it 00:22:22.980 --> 00:22:26.620 yourself on the blockchain. So it's kind of a non-interactive thing where as a 00:22:26.620 --> 00:22:32.100 seller, I can just, make this PSBT, sign my part of it, send it somewhere off to 00:22:32.100 --> 00:22:35.380 a website and forget about it. And one day I wake up and there's money in my 00:22:35.380 --> 00:22:38.080 wallet and the ordinal inscription, whatever it is, is gone. 00:22:38.300 --> 00:22:44.120 Yeah, so we've mentioned the empty fields of a PSBT. And so you publish a 00:22:44.120 --> 00:22:45.860 PSBT with some of these fields empty. 00:22:47.210 --> 00:22:50.550 Actually, probably most of the fields are empty, right? Like really the only 00:22:50.550 --> 00:22:55.170 field that's not empty is one of the outputs and the amount there. 00:22:54.980 --> 00:22:57.180 Like you just—so the, the workflow… 00:22:56.030 --> 00:22:59.110 And I guess one of the inputs, which has to be the ordinal. 00:22:59.870 --> 00:23:02.370 Yeah, the workflow is a little bit different than you might be used to because 00:23:02.370 --> 00:23:05.950 for a multisig, the transaction, if you're doing a multisig, the transaction is 00:23:05.950 --> 00:23:09.750 generally complete, but it's missing signatures. And in this case, the 00:23:09.750 --> 00:23:13.800 transaction is incomplete in the sense that it even misses inputs and outputs. So 00:23:13.800 --> 00:23:18.800 because the thing I just published as a seller is not going to be accepted on the 00:23:18.800 --> 00:23:23.140 blockchain. Because it is a transaction that is spending more than it's sending. 00:23:23.160 --> 00:23:27.500 Because what it's sending is just some satoshi. So it's only spending one 00:23:27.500 --> 00:23:31.900 satoshi. And it tries to have an output of, I don't know, 100 Bitcoin or whatever 00:23:31.900 --> 00:23:37.260 I asked for my amazing NFT. So somebody will have to provide that input. Yeah, 00:23:37.340 --> 00:23:40.100 and that's the buyer has to add their own inputs. 00:23:41.980 --> 00:23:46.400 So then how do you make that into a Dutch auction? Well, the idea is very simple. 00:23:46.620 --> 00:23:51.880 I, as a seller, create this transaction which has sent me one Bitcoin. And then 00:23:51.880 --> 00:23:55.060 after some time, I create another transaction that says, okay, whatever, 00:23:54.920 --> 00:24:00.160 send me 99—or send me 0.99 Bitcoin. And then a while later, I make one that says 00:24:00.160 --> 00:24:05.190 send me 0.98 Bitcoin until somebody actually publishes something on the 00:24:05.190 --> 00:24:08.990 blockchain. So I keep an eye on the mempool probably. And as soon as I see... 00:24:09.460 --> 00:24:14.580 this money coming towards me I will stop making new PSBTs. Yes, unless of course 00:24:14.580 --> 00:24:16.080 it's double spent and I just try again. 00:24:16.080 --> 00:24:20.340 Yep, I think that's that's also how Bitcoin Magazine did it so they published a 00:24:20.340 --> 00:24:25.860 new PSBT I think maybe every block or otherwise maybe it was every hour or 00:24:25.860 --> 00:24:31.380 I don't remember exactly but yeah so the price for each new 00:24:31.380 --> 00:24:34.940 PSBT went down and if someone wants to pick it up you know. 00:24:34.940 --> 00:24:39.300 Yeah, so in theory you could publish a whole bunch of PSBTs in one go and use 00:24:39.300 --> 00:24:44.200 time locks but this will create problems but what you could do is say well at you 00:24:44.200 --> 00:24:49.200 can commit inside the PSBT or you can say okay this can only be spent after this 00:24:49.200 --> 00:24:53.540 height this can only be spent after that height and that means whoever wants the 00:24:53.540 --> 00:24:58.920 the NFT or whatever it is from you will have to you know take that transaction 00:24:58.920 --> 00:25:04.130 and and make sure that it's confirmed before the next round because otherwise 00:25:04.130 --> 00:25:08.590 some other person might take the lower fee It might take the lower price, sign 00:25:08.590 --> 00:25:09.690 that, and pay a higher fee. 00:25:10.770 --> 00:25:16.230 Wait, what you're saying is there are several things you could be saying, and I'm 00:25:16.230 --> 00:25:17.290 not sure which one it is. 00:25:17.410 --> 00:25:17.630 Okay. 00:25:17.750 --> 00:25:20.750 But that's also because I wasn't paying attention because I was thinking about 00:25:20.750 --> 00:25:21.830 the next step in the podcast. 00:25:22.130 --> 00:25:22.430 All right. 00:25:22.750 --> 00:25:27.650 So what you were saying is if... there's several people during the same block 00:25:27.650 --> 00:25:32.450 that pick up, that both want to buy it, then it becomes a bidding war of fees, 00:25:32.570 --> 00:25:33.590 right? Is that what you were saying? 00:25:33.690 --> 00:25:36.770 No, we didn't cover that yet. That's actually interesting. No, I was covering a 00:25:36.770 --> 00:25:40.940 scenario where you create multiple PSBTs. At the same time, 00:25:40.760 --> 00:25:41.100 Yeah, 00:25:41.040 --> 00:25:44.580 you put them all on the website and you just say the first one can only be spent 00:25:44.580 --> 00:25:46.420 after this height. the second one… 00:25:46.140 --> 00:25:47.980 With time locks, that's what you were saying. 00:25:47.940 --> 00:25:48.260 Exactly. 00:25:48.140 --> 00:25:50.360 See, I wasn't paying attention at all at 00:25:50.320 --> 00:25:51.260 No, clearly [unclear]. 00:25:50.360 --> 00:25:54.640 this moment. Okay, you were talking about the time lock solution and the problem 00:25:54.640 --> 00:25:55.320 with that was? 00:25:55.580 --> 00:26:00.880 The problem with that is that as a buyer, let's say I'm okay with the highest 00:26:00.880 --> 00:26:05.700 price, I sign it, but I put a very low fee on it. Now after a block or two or 00:26:05.700 --> 00:26:09.280 whatever the next interval is, Some other person takes the second highest price 00:26:09.280 --> 00:26:13.480 and puts a higher fee on it. And they might be able to get into a block earlier 00:26:13.480 --> 00:26:16.400 than me. So even though they paid a lower price, they still win the auction. 00:26:16.600 --> 00:26:20.440 Yeah. Well, yeah. So that's why you can only publish one PSBT at the time. You 00:26:20.440 --> 00:26:21.720 really can't publish them all. 00:26:21.780 --> 00:26:24.140 It just depends on how much chaos you're willing to accept. But as a seller, of 00:26:24.140 --> 00:26:28.240 course, you have an incentive to get the highest price for it. So it's not a good 00:26:28.240 --> 00:26:31.320 idea as a seller to publish a lower offer. 00:26:32.610 --> 00:26:34.890