 Lewis asks, Transaction Validation and Script Construction, I would like to learn more about transaction validation and the two types of scripts to validate transactions, a locking script and an unlocking script. And how do these operate in transactions? Paul also wants to learn more about this. So let me go into that for just a tiny, tiny bit. Now, we talked about Bitcoin addresses. And in the past, we've talked about addresses in general. We talked about how the address represents the double hash of the public key. Now, when you tell your wallet, send crypto to this address, your wallet in the background constructs a transaction. And in that transaction, it puts a special script. I'll talk about Bitcoin specifically. Other cryptocurrencies may use slight variations on this general idea, but often it's a similar type of approach. So in the case of Bitcoin, when you say, send Bitcoin to the address one, blah, blah, blah, blah, and it's a one address, a traditional double hash of a public key address, what your wallet does is it constructs a transaction that has an output with a locking script in it. And what the locking script is, is a script in the Bitcoin scripting language that says, check that whoever tries to redeem this presents a public key that when double hashed matches this address that I'm trying to send money to, and a signature that can be validated against the public key we just double hashed. That script, which is take the public key, double hash it, check against the Bitcoin address, and then validate the signature. It's called a pay to public key hash script. It's a classic script that you'll see. It's the first lesson you see when you learn about scripting in the Bitcoin scripting language, and that is the locking script. So when you create a transaction that says, pay one Bob as an address, and it's a one address, your wallet actually creates a transaction that says, I'm locking this amount of Bitcoin to the pay to public key hash locking script that will match this address. And that's the locking script. Now that money has been locked against that locking script. If the recipient of that, the person who owns that address wants to spend it, they have to present an unlocking script that when combined with the locking script unlocks the amount. And that unlocking script is a public key that they own and a signature that they can generate with their private key. And since they're the only ones who have the private key, only they can produce this unlocking script. Now, when you take the unlocking script of public key and signature and you match it against the locking script of public key, double hash, Bitcoin address, check signature, and you put them together, it takes the public key that's unlocking, it double hashes it, checks it against the Bitcoin address, and if it matches, it will then check that the signature also matches that public key for that transaction. And that means that together, the locking and unlocking script allow you to send money by locking it to someone who can show ownership of a Bitcoin address. And the person who owns the corresponding private key is the only person who can construct the unlocking script that fits that lock in order to release that money in their own transaction to pay someone else. And so each time a transaction happens, it is a sequence of unlock this, unlock this, unlock this, and then lock it here, lock it here, lock it here. The simplest transaction is one input, unlock this amount, one output, lock it to a different script. And these get chained together where each unlocking script refers to a previous locking script and each future locking script can only be unlocked by another unlocking script that locks amounts to another locking script, et cetera, et cetera. So bits of Bitcoin are basically getting locked and unlocked and locked and unlocked in each sequence of transactions as they change ownership or as the value is moved from one Bitcoin address to another. I say moved within quotes and I say send within quotes because of course Bitcoin is never transmitted, it never moves. It's locked to one locking script and then it's unlocked and locked to another locking script. The Bitcoin hasn't moved. All that's changed is the effective control of that Bitcoin by changing the locking script and the conditions on which this amount can be spent. So that's the process of what's happening behind the scenes and we're gonna talk about that with a bit more detail in future lessons. Marcus asks, how exactly is the signature of a transaction verified by their miner or node? So first of all signatures on transactions are verified by every participating nodes, not just miners, but every node running on the system, including any wallet that sees that transaction. A signature is again a number. In fact, it's a pair of numbers and out of tradition we usually note those as R and S. R and S are the two parameters of a signature. Think of them as two numbers and they are produced through a mathematical formula that takes your private key and a message that you want to sign, which is the transaction that you're signing and uses the private key to produce a signature, which are these two numbers, R and S. There's another component though, which is the generation of a random number as part of that process and that is a critical component of that, but I'm not gonna go into that much detail. Let's say you take your private key and the message and you produce a signature, R and S. The unique thing about the formula that is used, the algorithm that is used to produce those numbers, R and S, is that anyone can then take the numbers, R and S, the message M that you signed and your public key, not private, your public key, and can do a calculation that validates that the signature produced was produced by the private key without knowing the private key. So if you can validate when you have a public key and a message and a signature, that that signature could only have been produced by someone who had the corresponding private key without having the private key yourself. That is the basis for digital signatures and that uses a mathematical trick in the elliptic curve field. One of the tricks about the elliptic curve, as I mentioned before, is that you can't reverse certain types of calculations on the elliptic curve and it uses a trick, a mathematical trick that gives you that with signatures. So a signature that is produced with a private key can be verified with a public key and that way when you sign a transaction with your private key and other people can then verify that signature against the public key, they know that you signed it without you revealing your private key. In the case of a Bitcoin transaction, when you sign a transaction, you also produce the public key. Remember previously, an amount of crypto may have been locked to your Bitcoin address, not your public key, but if you want to sign to unlock that script and spend that amount of Bitcoin, you have to also produce your public key and that's verified against the Bitcoin address, it's verified against the signature and then people know that you are in fact the authorized owner of those funds and are authorized and control them through your private key to spend them. Adrenal asks, transactions not included in a block. What happens to transactions selected by miners that don't become part of the block? Do they go back to the network and wait for the next block? Are nodes that are not mining receive any awards? Okay, first of all, nodes that are not mining do not receive any awards. Now you might talk about this idea of a reservoir or in fact, every node having its own reservoir or copy of a reservoir where they put transactions that haven't been confirmed yet. So they could keep a track of what transactions are not yet confirmed and waiting for inclusion in a block. Now this reservoir is obviously very important. The mempool is what it's called. Miners have this mempool and they use it to collect transactions in between blocks so that when they're ready to produce a block or to try to solve a block, they have transactions to put into that block so they can earn fees. When they take transactions out of that mempool and they put them in their candidate block, if that block is successfully solved and propagated to the rest of the network, as other nodes in the system see that block, they will look at what transactions are in the block and they will remove those transactions from their own mempool because they're no longer unconfirmed, they're confirmed. They're now in a properly solved block. And so the queue gets shorter if you think of it that way. The queue of remaining transactions gets slightly smaller every time a block is solved. Now there are some circumstances where blocks may get rejected after they've been solved and what happens then is really, really simple. If a block is rejected and we'll talk about that when we talk more about forks, then all of the transactions that were in that block, if they're not included in another block, will get dumped back into the mempool so they can wait their turn again. They don't get ignored, they don't get forgotten, they just go back in line and wait again and they'll be once again sequenced by priority of fees per byte so that the ones that are paying the highest fee get included in the next block, et cetera, et cetera. So transactions don't get dropped if they're included in a block and that block is invalidated, they get queued again in the mempool to be included in the next block. If a transaction just sits in the queue and doesn't get included in a block, usually because its fees are too low, then eventually that transaction will get dropped from the mempool and each node decides how long it's gonna keep transactions in the mempool, how big its mempool it's going to be and that depends on how much RAM it wants to allocate to the mempool function, but effectively that transaction will eventually get dropped from the network and your wallet may need to create a new one with a higher fee or retransmit it hoping that this time the network is more empty and it has a chance of getting through even with a low fee.