Episode 28: Explaining Bitcoin Addresses

Aaron van Wirdum Before the show, a quick word from our sponsor. Live from Utrecht, this is the Van Wirdum Sjorsnado.

Sjors Provoost Hello.

Aaron van Wirdum Hey, Sjors.

Sjors Provoost What's up?

Aaron van Wirdum The other day I wanted to send Bitcoin to someone, but I didn't.

Sjors Provoost Shouldn't you hodl?

Aaron van Wirdum I hodl all I can, but sometimes I need to eat, or I need to pay my rent, or I need to buy a new plant for my living room.

Sjors Provoost Yeah, that's true.

Aaron van Wirdum So the problem was the person I wanted to send Bitcoin to, I didn't have their IP address.

Sjors Provoost You did not have their IP address.

Aaron van Wirdum I did not have their IP address.

Sjors Provoost Okay.

Aaron van Wirdum Luckily, it turns out there's this trick in Bitcoin called Bitcoin addresses.

Sjors Provoost That's right.

Aaron van Wirdum Have you heard of this?

Sjors Provoost Yes.

Aaron van Wirdum Maybe our reader, cut that please. Maybe our listener hasn't yet, Sjors. So let's explain what Bitcoin addresses are.

Sjors Provoost Okay. What are Bitcoin addresses?

Aaron van Wirdum First of all, so I made a stupid joke about IP addresses, but this was actually an option, wasn't it?

Sjors Provoost Yeah, so in the initial version of Bitcoin, Satoshi announced it on the mailing list and said, well, if you want to send somebody some coins, you just enter their IP address and then it'll exchange, I guess, an address to send it to.

Aaron van Wirdum Yeah so it was actually possible to send bitcoins to people's IP addresses. I don't think that's possible anymore. That's not in any of the code.

Sjors Provoost I don't think so either. I haven't seen it. Yeah because the other way is that you just get an address to send to and then it goes to the blockchain and because the other side is checking the blockchain also it'll show up yeah.

Aaron van Wirdum Well, that's actually not how it works at all. But we're going to explain it now, I think.

Sjors Provoost Yep.

Aaron van Wirdum Let's go. Okay, first of all, Sjors, when you send Bitcoin to someone, what do you actually do? What happens?

Sjors Provoost Well, you're creating a transaction that has a bunch of inputs and it has an output. And that output describes who can spend it.

Aaron van Wirdum Yeah.

Sjors Provoost So you could say anybody can spend this. That's not a good idea. We talked about that in an earlier episode. So what you do is you put a constraint on it. And the very first version of that constraint was he or she who has this public key can spend the coins. So that's called pay to public key.

Aaron van Wirdum Yes, exactly. And then we just mentioned this IP example. So what actually happened was you would connect to someone's IP. I don't know the nitty gritty details, but in general, you would connect to someone's IP and you'd ask for a public key and that person would give you the public key. And I think that's what you send the bitcoins to.

Sjors Provoost Yeah, I believe so too, but I haven't seen that code in action, so we could be slightly wrong there. Somebody should dig it up. I'd love to see screenshots of what that used to look like.

Aaron van Wirdum Yeah, is there anyone who's ever used this way of paying someone pay to IP address?

Sjors Provoost Yeah, we'd love to know.

Aaron van Wirdum It was technically possible. If anyone listening... Has anyone ever actually used this? We'd be curious to hear that.

Sjors Provoost I mean, it makes sense to think that way in the first version of Bitcoin, right? Because before that, you had all these peer-to-peer applications and they were generally very direct. So with Napster and all these things, or Kazaa, I don't know which one, you would connect to other people and you would download things from them. And with Bitcoin, you connect to other peers, but nowadays you just connect to random peers. But perhaps in the beginning, the idea might have been, okay, you connect to peers you know, and so then you might as well, you know, do transactions with them. But right now you don't really do transactions with the peers you're directly connected to, at least not in Bitcoin on chain.

Aaron van Wirdum Yeah. Well, anyway, so that's one way of paying someone to a public key is you'd connect to their IP address and you'd get their public key. The other way is if you mine Bitcoins. So if you're a miner, then you're actually sending the block rewards to your public key. Is that still the case? It used to be the case in the beginning, at least.

Sjors Provoost Well, in the beginning, Bitcoin had a piece of mining software built into software, right? So if you if you downloaded the Bitcoin software, it would just start mining. And so it would use that mechanism.

Aaron van Wirdum Well, you just have to press a button, but yeah.

Sjors Provoost Yeah, I guess. And then later on, you know, you had mining pools and it all became more professional. So the way they would pay out might be very different. Probably, you know, might go to a multi-sig address from which it's paid back to the individual pool participants. Or it could be paid directly to the pool participants, although that's a bit inefficient because you need a long list of addresses in the coinbase. But I've seen huge coinbase transactions, so probably people were doing that.

Aaron van Wirdum Right. Well, anyway, so the point I was making was this pay to public key way of paying someone. I learned this while doing a little bit of research for the show. That was only ever really used for pay to IP address and for the miner, the block reward.

Sjors Provoost Okay.

Aaron van Wirdum It wasn't actually used for anything other than that. What was used? Other than that was pay to public key hash, right? So you're not sending money to a public key, but you're sending money to the hash of that public key.

Sjors Provoost Yeah.

Aaron van Wirdum And this is where addresses come in.

Sjors Provoost Yeah.

Aaron van Wirdum And this type of payment actually used addresses for the first time. Not for the first time. This was always there. Also something I learned while doing a little bit of research. This was there since day one. There were Bitcoin addresses since day one, but they were only there for pay to public key hash.

Sjors Provoost Right, so basically so the script on the Bitcoin blockchain would in that case say okay the person who can spend this must have the public key belonging to this hash so you know the nice thing about that is that you're not saying which public key you have or at least at the time it was thought that maybe that was safer against quantum attacks but the other benefit is that it's a little bit shorter so it saves a bit on block space although of course that wasn't an issue back then. So yeah, you pay to the public key hash.

Aaron van Wirdum Yeah, I guess in a way it's slightly more private as well, right? Because you're only revealing your public key when you're paying. No, that doesn't make sense.

Sjors Provoost No, I think that exactly doesn't matter.

Aaron van Wirdum No. Okay, so that's paying to public key hash. And like you said, what you see on the blockchain itself, what's recorded on the blockchain, is the actual hash of a public key. However, when you're getting paid on a public... pay to pub key hash, what you're sharing with someone is not this hash; it's actually an address.

Sjors Provoost Yes, well you are sharing the hash but you do that using an address.

Aaron van Wirdum Exactly, so what is an address?

Sjors Provoost So an address essentially is at least this type of address is the number one followed by the hash of the public key but it is encoded using something called base 58.

Aaron van Wirdum What's base 58?

Sjors Provoost Okay, so let's go back to base 64. I don't know if you've ever seen an email source code, like an attachment, all these weird characters in there. That's base 64. And base 58 is based on that. But maybe to say what it is, it is all the lowercase letters, all the uppercase letters, and all the numbers, and without any of the signs, and with some ambiguous things removed. So you do not have the small O, the big O, and the zero.

Aaron van Wirdum Should we start with base 10?

Sjors Provoost Yeah. So, I mean, there's two things.

Aaron van Wirdum I want people to understand what base means.

Sjors Provoost Yeah, exactly. So this is what's in base 58, but then the question is, what is base?

Aaron van Wirdum Yes.

Sjors Provoost And so base 10 is you have 10 fingers. And so if you want to express, say, the number 115, you can make three gestures, right? You show a 1 and a 1 and a 5. And that is base 10 because you're using your 10 fingers three times. And that's also how you write down numbers. But there have been different bases. I think the Babylonians were very much into base 360. That's why we have…

Aaron van Wirdum Hang on, hang on. Because we're not actually using fingers most of the time. So I want to make this clear that it just means we have a decimal system. So that means we have 10 different symbols that represent the number.

Sjors Provoost That's right.

Aaron van Wirdum The symbol zero, which is a round thing, and then we have the one.

Sjors Provoost But it's probably not a coincidence that that happens to [unclear]…

Aaron van Wirdum I totally agree. I just want to make it clear that we're not actually using fingers most of the time.

Sjors Provoost No, and so the…

Aaron van Wirdum Okay, so we have 10 symbols, so that means that once you get by the 11th number, at that point, you're going to have to reuse symbols you've already used, or you're now going to use combinations. So in our case, that would be... Well, it's going to get confusing because the first number is a zero. So then the 11th number is the 1 and the 0.

Sjors Provoost Yeah, exactly. And there have been different bases in use, right? So base 360, I believe, was used by Babylonians, or maybe base 60. And then for computers, we tend to use base 2 internally, because chips are either on or off. So it's a 0 or a 1, so a long series of 0s and 1s. And you can express any number of that. Now, in order to read machine code, typically you would use hexadecimal, which is base 16. So that is 0 to 9 and then A to F.

Aaron van Wirdum Yeah.

Sjors Provoost Right, and so base 58 is basically this 58 possible characters to express something with.

Aaron van Wirdum Yeah, it's it's all it's all numbers and there's different ways of expressing a number based on your base. Yeah, and that determines how many symbols you're using.

Sjors Provoost The trade-off here is readability, really, because you could represent machine code as normal characters. So the ASCII alphabet or the ASCII character set is 256 different characters. So that's base 256. But if you've ever done something like print and then the name of a file, your computer will show complete gibberish on the screen and it will start beeping. And the reason it starts beeping is because one of these... codes somewhere in the base 256 is a beep which actually makes your terminal beep so it is completely impractical to view a file using base 256 even though there is a character for every of the 256 things there so that's why you tend to do that in base 16 hexadecimal is relatively easy to read but then it's quite long if you take a public key and you write it as hexadecimal it's it's a rather long thing to write down but and base 58 is a little bit shorter so maybe you know it's easier to copy paste perhaps or it's not even easy to read on the phone. Base 58 is pretty terrible because it's uppercase, lowercase, uppercase, lowercase.

Aaron van Wirdum Yeah. Okay. Just to restate that briefly. So base two is just, you're just using two symbols, which is one and zero. And base 10 is what we use most of the time. It's zero, one, two, three, four, up until nine. Then you have hexadecimal, which uses zero through nine plus A, B, C, D, E, F. And then what we're talking about here is base 58, which uses 58 different symbols, which are zero through nine. Most of the alphabet in both capital letters and undercase, right?

Sjors Provoost Yeah, I think it's lowercase and uppercase and then most of the numbers, but there are some letters and numbers that are skipped that are ambiguous. So the number zero, the letter O, both lowercase and uppercase, or at least uppercase is not in there.

Aaron van Wirdum Yeah, I think, for example, the capital I and the lowercase L are both not in there because they look too similar.

Sjors Provoost Right, and that's why you get a little bit less than, you know, if you just add 26 letters plus 26 uppercase plus 10 numbers, right?

Aaron van Wirdum Okay, I think we finally explained what base 58 means.

Sjors Provoost Yeah, and just as a sidestep, I talked about email earlier, that's base 64. That is the same, but it also has some characters like underscore and plus and equals. And that was mostly used for email attachments. And I guess they didn't want to use all 256 characters either because they didn't want the email to start beeping, but they did want to squeeze a lot of information into the attachment.

Aaron van Wirdum Okay, that's base 58. Now, why are we talking about this? What is an address?

Sjors Provoost Yeah, so the address again is actually the value 0, I believe, but that's expressed as a 1, because that's the first digit in this character set.

Aaron van Wirdum Base 58 system, yeah.

Sjors Provoost Yeah, so it starts with a 1, and then it's followed by the public key hash, which is just expressed in base 58.

Aaron van Wirdum Right, is that all it is?

Sjors Provoost Yes. And keep in mind, so that is the information you send to somebody else when you want them to send you Bitcoin. You could also just send them 00 and then the public key. And maybe they would be able to interpret that. Probably not. You could send them the actual script that's used on the blockchain. Because on the blockchain, there is no base 58 or base 64 or anything like that. The blockchain is just binary information. So the blockchain has this script that says if the person has the right public key hash, has the public key belonging to this public key hash, then you can spend it. And we talked about in an earlier episode how Bitcoin scripts work. So you could send somebody the Bitcoin script in hexadecimal, anything you want. But the convention is you use this address format. And that's why all traditional Bitcoin addresses start with a one. And they're all the same, roughly the same length.

Aaron van Wirdum Okay, so a Bitcoin address is basically just a base 58 representation of a version number plus a public key hash. Sjors, is base 58 used for anything else in Bitcoin?

Sjors Provoost Yeah, you can also use it to communicate a private key. And in that case, your version number is, well, it's written as 5. But it actually represents, I think, 128.

Aaron van Wirdum Right.

Sjors Provoost And then followed by the private key.

Aaron van Wirdum So that's why all private keys start with a 5. Or at least used to start with a 5.

Sjors Provoost Yeah, so in the old days you had paper wallets that you could print. And if you generate them actually securely without a backdoor, then on one side of the piece of paper you would have something starting with a 5. And on the other side of the paper you would have something starting with a 1. And then it would say, like, show this to other people and don't show this to other people.

Aaron van Wirdum Right. Now, I happen to know, Sjors, that there are also addresses that start with a three.

Sjors Provoost That's right.

Aaron van Wirdum What's up with that?

Sjors Provoost Well, usually those are multi-signature addresses, but they don't have to be. They could be single-signature addresses. What they are are...

Aaron van Wirdum They could also be types of SegWit addresses or... They could be many things, right?

Sjors Provoost Yes.

Aaron van Wirdum They could also be... Single sig, but you already mentioned that. So let's go on. Okay, three. What does it mean?

Sjors Provoost So it basically says pay to public key hash. So it is that number followed by…

Aaron van Wirdum Pay to public script hash.

Sjors Provoost Sorry, public script hash. Well, not even public, just pay to script hash.

Aaron van Wirdum We're getting there eventually. Pay to script hash.

Sjors Provoost Yes, and it says basically anybody who has the script belonging to this hash. And who can satisfy the script. So just knowing the script is not enough you actually have to do whatever the script says you should do.

Aaron van Wirdum Yeah so the first version we just described was pay to public key hash which required people to offer a valid signature corresponding to the public key and now we're talking about pay to script hash which means someone needs to present the script and be able to solve the script. So why do these start with a three?

Sjors Provoost This is a convention, so as we said, there is a... Basically, a version number that everything that you communicate through Base58 starts with a version number. And if it starts with a 1, then you know it's paid public key hash. If it starts with a 3, you know it's paid script hash. If it starts with a 5, you know it's a private key. So it's just a convention, and it has no meaning on the blockchain itself.

Aaron van Wirdum Once again, all this is is a version number plus this hash represented in Base58. Is that all it is?

Sjors Provoost Yeah.

Aaron van Wirdum This is all. So much simpler than I once thought Sjors.

Sjors Provoost No, it's really simple. And the only mystery that has been solved today, I guess, is, well, what if you only use the public key, but that wasn't done using this system. So there is no initial letter that would represent trying to do that.

Aaron van Wirdum Yeah that was never represented.

Sjors Provoost Otherwise… otherwise probably that would have been version zero, and then all normal addresses might have started with the two. Who knows?

Aaron van Wirdum Okay I think for anyone who already knew this which is probably a good chunk of people this is a very boring episode so far but I think it's gonna get better because oh my god because Sjors, we now have a new type of address since I don't know a year or two which starts with bc1

Sjors Provoost BC1Q even, usually.

Aaron van Wirdum Yeah, usually, but not always. And we're getting into that, I think.

Sjors Provoost Yep.

Aaron van Wirdum So what is this all about?

Sjors Provoost Well, that is Bech32 or Bech32 or however you want to pronounce it. And it's been used since SegWit, basically. And again, it is something that doesn't exist on the blockchain. So it's just a convention that wallets can use. This is a, as the name suggests, a Base32 system, which means you have almost all the letters and almost all the numbers minus some ambiguous characters that you don't want to have because they look too much like numbers or letters.

Aaron van Wirdum Yeah, and I think one of the big differences compared to base 58 is that this time there are no longer... uppercase and lowercase letters there's just any… every letter is only in there once.

Sjors Provoost Exactly. The other difference is that it has a benefit…

Aaron van Wirdum I'll mention one benefit of that which is that if you want to read an address out loud it's going to be a little bit easier now that there's no difference between uppercase and lowercase.

Sjors Provoost Yeah and the other difference is, I didn't check with base 58 but basically it doesn't start with zero or anything like that it's it looks pretty arbitrary so The value 0 is written as a Q. The value 1 is written as a P. The value 2 is written as a Z, etc.

Aaron van Wirdum Why is the value 1 just written as a 1?

Sjors Provoost Well, it's completely arbitrary, first of all, right? You can connect any value to any symbol you want.

Aaron van Wirdum Sure.

Sjors Provoost If there is a human interpretation that depends on it, then you don't want to do anything confusing. But if your only goal is to make it easy to copy-paste things, and if your other goal is for every address to start with bc1q, because bc1 sounds cool, then maybe there's a reason why you want to do them out of order. I haven't read what the rationale is in the order.

Aaron van Wirdum Okay, now Bech32.

Sjors Provoost Yeah, so there's a set of 32 characters, and… that means you're… but it's doing the same thing, right? It's again saying, okay, here's a pay to public key. Yeah, a pay to public key address. In this case, a pay to witness public key because it's using SegWit, but it's the same idea, public key hash. So it says, hello, and then followed by the hash of the public key.

Aaron van Wirdum Okay, so Bech32 addresses, what are we looking at exactly? Because what we're seeing for each address, it starts with B, C, 1, and then usually a Q, and then a whole bunch of other symbols. So what does this all mean?

Sjors Provoost That's right. So there is something called the human readable part. And that doesn't really have any meaning other than that humans can recognize, okay, if the address starts with BC, then it refers to Bitcoin. And the software, of course, can see this too, but both humans and software can understand this.

Aaron van Wirdum Yeah, so if Litecoin would want to use these kinds of addresses, maybe they do actually, I don't know.

Sjors Provoost Probably, then they might start with LT.

Aaron van Wirdum Exactly. So these first two letters just refer to which currency is this about? What blockchain is this for?

Sjors Provoost Yeah, and it can be, I think, a fairly arbitrary number of letters. The idea is that it's separated by a one.

Aaron van Wirdum Oh, it could be more than two letters as well?

Sjors Provoost Yeah, I think initially Bitcoin Cash was using a much longer introduction.

Aaron van Wirdum I see, okay.

Sjors Provoost So that's pretty arbitrary. Obviously, you want to conserve space. So BC is nice and short. And a one, that's a separator, has no value. So if you look at what do all the 32 numbers mean, then one is not in it.

Aaron van Wirdum One just means…

Sjors Provoost Skip this.

Aaron van Wirdum The human readable part is over. Now the fun stuff starts.

Sjors Provoost Now the meat and potatoes.

Aaron van Wirdum Right.

Sjors Provoost And the fun stuff, it's a little bit easier, actually, than with Base58, because there's a convention that says if it's... Well, the convention is it starts with the SegWit version. So the first version of SegWit is 0, which in Bech32 is written as Q. And then it's either followed by 20 bytes or 32 bytes. And that is… then it means either it's the public key hash, or it is the script hash. And they're different lengths now because SegWit uses the SHA-256 hash of the script rather than the RIPEMD 160 hash of the script. So in Base58, the script hash is the same length as the public key hash, but in SegWit, they're not the same length. So simply by looking at how long the address is, you know whether you're paying to a script or you're paying to a public key hash, so we don't have to say it.

Aaron van Wirdum Right, so to reiterate the first two letters, PC, that just means this is about Bitcoin. Then the one says, okay, that was the… part telling you which currency this is, now pay attention to what you're actually going to pay money to. Then the Q means which version is going to follow, which version of address.

Sjors Provoost Yep.

Aaron van Wirdum And then what comes after that?

Sjors Provoost Which version of SegWit.

Aaron van Wirdum Yeah, what comes after it is actually the Bech32 representation of this hash. Which is either pay to public key hash or pay to script hash.

Sjors Provoost Yeah, exactly. Or pay to witness public key hash or pay to witness script hash.

Aaron van Wirdum Sjors, is there anything else cool about Bech32?

Sjors Provoost Yeah, there is. And it's about error correction. So in base 58, there is a checksum. So a checksum basically means you add something to the address at the end. And that way, if you make a typo... then that checksum at the end of the address is not going to work.

Aaron van Wirdum [unclear] going to compute with the rest of the address.

Sjors Provoost So it'll tell you, okay, this address is wrong.

Aaron van Wirdum Right.

Sjors Provoost Now there is a certain chance…

Aaron van Wirdum It doesn't tell you what the correct version would be. It just tells you this is wrong.

Sjors Provoost Exactly. Now there is, you know, there's a chance that you make a typo that happens to have a correct checksum. I don't know what the odds are with base [unclear]. They're pretty low.

Aaron van Wirdum You'd probably have to make several typos.

Sjors Provoost Well, yeah, you'd have to have the unlucky typo. I don't know if the odds are 1 in 10,000 or 100,000 or something.

Aaron van Wirdum Right.

Sjors Provoost But, you know, there's a lot of Bitcoin users. But in Bech32, it's actually better because it will not just tell you that there's a typo. It'll tell you where the typo is. And that's done differently. So where we talked about in the Base 58 system, there is a checksum, which just... takes all the bytes, basically takes all the bytes from the address and then hashes it. Here there is very sophisticated mathematical magic. I don't think it's super sophisticated, but I can't explain what the actual magic is. But the magic makes it so that you can actually make a typo and it'll actually tell you where the typo is. And you can make about four typos and it'll still know where the typo is and what the real value is. If you do more than that, it won't. And the analogy I like to make with that... as someone once told me is it's like if you have a wall and you draw a bunch of circles on it and each circle represents a correct value and you're throwing a dart at it and you know you might hit the bullseye then you have the right value or you might just slightly miss the bullseye but you're still within that big circle then you know you know you know exactly where it should have been.

Aaron van Wirdum Are you talking about interlocking circles?

Sjors Provoost No, they're not overlapping.

Aaron van Wirdum Okay.

Sjors Provoost So the idea there is you want the circles to be as big as possible, obviously, but you don't want to waste any space. So that's an optimization problem in general. And of course, in the example of a two-dimensional wall with two-dimensional circles, it's pretty simple to visualize, right? You throw the dart and you see, okay, it's still within the big circle, so it should belong to this dot. So that is like saying, okay, here's your typo and this is how you fix it.

Aaron van Wirdum Right.

Sjors Provoost But, and in the case of Bech32, the way I think you should imagine it is that instead of a two-dimensional wall, you have a 32-dimensional wall, and the circles are also probably 32-dimensional hyperspheres.

Aaron van Wirdum I find that a little bit hard to imagine, Sjors, but I'm not a wizard like you.

Sjors Provoost Well, if you've studied something like physics or math, you know that anything you can do in two dimensions, you know, you can see it in three dimensions, and you can do it in n dimensions, you can abstract all these things out too… to as many dimensions as you need. But the general intuition is the same. So now you're hitting your keyboard, and somewhere in that 32-dimensional space, you're slightly off, but you're still inside this sphere, whatever that might look like. And so it knows where the mistake is. But there's a problem.

Aaron van Wirdum Oh.

Sjors Provoost Yes.

Aaron van Wirdum Oh, no.

Sjors Provoost All this amazing wizardry missed something. And it basically…

Aaron van Wirdum It lost me a long time ago, but go on.

Sjors Provoost Well, basically, it turns out that if your Bech32 address ends with a P, then you can add an arbitrary number of Qs to it, and it still will match the checksum.

Aaron van Wirdum Oh, yeah, this is the bug. There was a bug in Bech32.

Sjors Provoost Yeah, so I guess the analogy would be that the circles are not entirely separate in some weird way, and that's not good, but that's actually not a problem originally.

Aaron van Wirdum So any address that ended with a P… could have any arbitrary numbers of Q following it, and then you wouldn't be told that there's a typo. Your software would think it's right, and then you're sending money to the wrong address.

Sjors Provoost Yeah, which means it's unspendable.

Aaron van Wirdum Right, yeah, yeah, exactly.

Sjors Provoost But the good news is that there's another constraint for the original version of SegWit, SegWit version 0, which is that an address is either, well, 20 bytes or 32 bytes.

Aaron van Wirdum Right.

Sjors Provoost And that means that it's constrained, right? Because if you add another Q to it, then it's too long. So you still know it's wrong.

Aaron van Wirdum Yeah, if you have a 20 byte address and you add one Q, then it's 21, which is still invalid. So you'd have to accidentally add 15 Qs or how many were?

Sjors Provoost 12.

Aaron van Wirdum 12 Qs.

Sjors Provoost Yeah, or something like that. I don't know.

Aaron van Wirdum That's pretty unlikely to happen.

Sjors Provoost Yeah, because I might be confusing bytes and characters, but exactly. That's very unlikely to happen for SegWit version 0. But now we would say, okay, we're going to have a new, you know, we're going to have future versions of SegWit, such as Taproot.

Aaron van Wirdum Right.

Sjors Provoost You know, it would be bc1p, because p is version one. And I believe for Taproot, there's also a constraint in how long these addresses are supposed to be. So it's still not an acute problem. But in the future, maybe we want to have addresses that are somewhat more arbitrary in length, because maybe you want to add some weird conditions to it. Or you want to communicate other information, not just the address. Maybe you want to put the amount inside the address.

Aaron van Wirdum Right.

Sjors Provoost So this is why there's a new standard proposed BIP 350, which is called Bech32m. And it's actually... a very simple change. I think it adds to the all the math. It adds one extra number to that math and then it fixes that particular bug and everybody's happy.

Aaron van Wirdum So it fixes the bug that the Qs don't matter anymore?

Sjors Provoost Yeah, you can't just add stuff to it without running into problems.

Aaron van Wirdum But I guess this does mean that wallets that have by now upgraded to support these special SegWit addresses, Bech32 addresses, they now have to upgrade again.

Sjors Provoost That's right. So that's annoying because it does mean that if your wallet wants to support sending to a Taproot address, then it has to make a small change to the Bech32 implementation. And there's some example code on the BIP. It's not a big change because it just adds one number. And if you look at the Bitcoin Core implementation, it's a fairly simple change. That does it. But it does mean that moving forward, when you see a Bech32 address, you have to parse it, then see if it's the version 0 or the version 1, and then do things slightly differently. But even that is just a very small change.

Aaron van Wirdum Right.

Sjors Provoost But it is annoying. Yeah, it does mean that especially hardware wallets with firmware updates could take a while.

Aaron van Wirdum Right. So we started out with base 58 addresses. Now we're all starting to use Bech32 addresses. Is this final? Are we going to keep using Bech32 or are you anticipating some other address format somewhere in the future?

Sjors Provoost No, I think this will do for a long time. Bech32 is a way to write addresses. Now, what is actually inside an address, there could be more information in it, right? And the most interesting example of that is Lightning Invoices. Lightning Invoices uses Bech32, but they're much longer because they contain a lot more information. They contain the public key. They contain the amount. They contain the deadline. They contain a bunch of secrets. They contain all sorts of stuff, all sorts of routing hints even. It's like a whole book you're sending over. So Bech32 is just an alphabet, essentially. You can make it as long as you want with this little caveat in mind that we talked about. But you're probably not going to manually type Lightning invoices anyway because they're too long. So you tend to copy-paste them.

Aaron van Wirdum Yeah, and generally you copy-paste any address. I don't retype addresses, do you, Sjors?

Sjors Provoost Well, you might, I don't know, you might have some like nuclear cold storage and the addresses for that nuclear cold storage might be written down on a piece of paper because you don't want them ever to touch anything that's on the internet. But, you know, generally people copy paste, but there was some discussion early on with Bech32, I think, that was explicitly talking about, can this be communicated over the phone?

Aaron van Wirdum Yeah, true. That's why there's this…

Sjors Provoost Even in your nuclear bunker situation, maybe you need to communicate something to somebody else in another nuclear bunker through smoke signals. And then, you know, you could use Bech32 for smoke signals, although maybe a Base2 system is easier. I don't know. I've never done smoke signaling.

Aaron van Wirdum No, I usually copy-paste.

Sjors Provoost Okay, that's cool. It's also like a smoke signal, just a bit more complicated. All right.

Aaron van Wirdum Was that everything there is to know about addresses, Sjors?

Sjors Provoost I'm sure there's more, but I think this is a nice primer.

Aaron van Wirdum You're going to call it a day?

Sjors Provoost We are. So thank you for listening to the Van Wirdum Sjorsnado.

Aaron van Wirdum There you go.