Video - Bitcoin - Transaction Records

At its core, Bitcoin is just basically a chain of digital signatures that really reflect the coins path through the Bitcoin ecosystem.  And here I think it's actually conceptually easier to think of Bitcoins as collective entries into a ledger rather than as a physical coin because if you think about it in a ledger you have a record of transaction histories which is what happens in Bitcoin, whereas with a physical coin, it's more like memory less, there's no history in a physical coin of where that coin has really been in the past, okay.  So in this context, you can think of a transaction is just a digitally signed declaration by one party of its intent to transfer some Bitcoins that they possessed to another set of parties.  And when I say one party possesses a certain number of Bitcoins, I really just mean here that there are some previous transaction on record that everybody's agreed to in which the party now transferring the Bitcoins was itself the recipient of a previous transfer of those Bitcoins, all right.
And I realized a bit convoluted so maybe to help better understand the mechanics of a transaction, I can do an example of what would happen in the context of an actual Bitcoin transaction.  So let's say we have a party and let's call her Alice which is the common name we use for parties in cryptographic schemes.  And let's say she wants to transfer some Bitcoins to Bob, okay.  And let's say she would like, has an intention of, wanted to transfer a 50 Bitcoins to Bob, okay.  Now, remember that anybody who transacts in the Bitcoin ecosystem is actually not transacting under their real name or their actual name but rather they are known by a very specific identity a pseudonym within the Bitcoin ecosystem and that identity, that pseudonym is actually would actually corresponds to a public verification key for a digital signature scheme.
So in this case, let's say Alice's identity on the system is really some public verification key which we'll call a VK of A.  So Alice's verification key.  And in the context of Bob let's say his public verification key is some VK, so B.  So these are keys that are used within digital signature schemes and so we can assume that Alice has generated this key at some point and that she made it public and that Bob did the same thing.  And so now they both have identities within the system and these identities are just sequences of numbers that correspond two public keys for verification in the context of a cryptographic digital signature, all right.
Now, remember that these values also correspond to private values.  So each person has got a public key, will have a corresponding private key associated with that public key and in this case we'll call the private key or the secret key which is in fact a sign in key in this context.  SK of Alice and we'll say that Bob sign in key is some SK of Bob, okay.   And they're going to basically keep this keys private.  Now, let's say that Alice herself had received in the past three transactions of Bitcoins from other party.  Let's say she got 25 Bitcoins from Carol and we'll call Carol VK of C to associate that what her key.  Let's say got, I don't know, 20 public or 20 Bitcoins rather from David and let's say she got 20 more Bitcoins from Ted, okay.  So these are -- these Bitcoins correspond to different people that provided Alice with Bitcoins in the past.
And so as you can see Alice now has an aggregate of 65 which is 20 plus 20 plus plus 25 Bitcoins.  And so as a result, she has a sufficient number to be able to transfer 50 of those Bitcoins to Bob, okay.  So to start off with, a transaction from Alice to Bob for 50 Bitcoins will contain information about these previous transactions.  So each of these previous transactions where Alice received some Bitcoins, this will have been recorded in the Bitcoin ecosystems, they're going to be made public just like every other transaction.  And so what Alice can actually do is she can take some representation of these transactions and include them as part of the new transaction with Bob.  Basically it's an anchor point to say, hey I received these previous Bitcoins and now I'm going to transfer some portion of these Bitcoins to you, Bob, okay.
So, you know, this context actually she does not need to include the full transaction details in the actual transaction record to Bob.  What she can instead do is take the transaction details and apply a cryptographic hash function to them to get a series of digests for each transactions.  So in this case, let's say she has a digest that corresponds to the transaction from Carol, she'll have a digest that corresponds to the transaction from David and she'll have a digest that corresponds to the transaction from Ted, okay.  And she'll basically include each of these digests into the transaction record and would these transaction allow you to do or really allow anyone to do for that matter, is they can verify the chain of ownership of these Bitcoins because they can simply take all the previous transaction records which again are made public, they can apply cryptographic hash functions to the in -- to these different transaction records and they can verify that these cryptographic hash is going to applied to those transaction records, provided you back with these values of D sub c, D sub d and D sub T.  And that in turn provides you with some type of a cryptographic guarantee because we're using cryptographic hash function, we have cryptographic guarantee that Alice was the ultimate recipient of these transactions from these different parties.  We have this nice history that we can record and that we can essentially ascertain in this fashion, all right.
And because we're using cryptographic hash function we now have some assurance that Alice couldn't have so easily cheated the system, all right.  So at this point in the transaction and maybe I'll kind of draw lines you can kind of see where the transaction details are recorded.  So at this point of the transaction we have details about Alice's ownership of these 65 Bitcoins and she has enough information in that transactions so that anybody can verify that she possessed these coins, all right.  So you can think of this part of the transaction really as representing the input, the input of the transaction.  Now, in addition to the input portion of the transaction, there's typically also an output portion.  I'm going to put that output portion up here, but let me label it, okay.
And so for starters, in the output portion she has to include or Alice has to include a list of recipients for her Bitcoin.  And since Alice wants to, let's say, transfer these Bitcoins to Bob, she has to specify Bob's identity in the system which in fact as we've mentioned earlier was Bob's public key.  So we'll say that she'll mention V sub k of B, okay.  And she also has to record and mention at this stage how many coins she wants to transfer to Bob and as we've said earlier we were going to assume that Alice wanted to transfer exactly 50 of her Bitcoins to Bob, okay, so she's going to specify the number 50.  Actually, in reality she'll specify another number but it's going to represent 50 Bitcoins for Bob, okay.
Now, in order for Alice to get that chain because she has 65 Bitcoins kind of coming in and she is only getting 50 back to Bob.  What she might then do is decide that she's going to specify 14 of those Bitcoins to be returned back to her in the form of a change, okay.  So 14 of those Bitcoins are going to be reassigned back to Alice's public key, all right.  And what Alice will then do is she's going to take all of this data this, this transaction data, this input and this output and she's going to digitally sign that data.  She's going to use her sign in key, her sign in key, to digitally sign all this data like you would with a digital signature and she's going to append that signature to the actual contents of the transaction record and that will effectively bind Alice's identity with the transaction record itself, okay.  And the reason it's going to bind it is we're using a digital signature scheme and so anybody who possesses Alice's public key which again is made public can validate that only Alice could have created this block because only Alice in theory can come up with a signature that corresponds to her public key because she's the only person who in theory should possess the private sign in key corresponding to her public key, all right.
Then all of this data will actually be broadcast out, so this transaction data will then get broadcast out to all the different peers and the nodes in the Bitcoin network.  So everybody in the Bitcoin network will basically know now that VK sub A is trying to send 50 Bitcoins to VK sub B, okay.  Now, at this point you may have noticed a slight discrepancy here that Alice started up with 65 points kind of on the input side, but on the output side she only has 50 plus 14 or 64 coins that are being accounted for, okay.  So, there is this issue what happens with this one last remaining coin, there's kind of this one implicit coin hanging around that has not been accounted for and what we're going to do with that coin is that coin is actually going to be used as a transaction fee.  Alice is going to be -- Alice is basically saying that that this one leftover coin should be provided as a transaction fee to what's known as a Bitcoin miner, okay.
And a Bitcoin miner, as I mentioned in the previous videos basically an entity in the Bitcoin system.  Anybody can be a Bitcoin miner actually, but it's a node in the Bitcoin network who engages really in the effort to help with the broader validation of this transaction.  So what do I mean by broader validation.  One, if you think about it at this point we've just used cryptographic hashing and digital signing to validate that Alice at some point possessed the requisite Bitcoins in the system and that she not only publicly announced her intention to transfer some of the Bitcoins to Bob but she digitally signed that that public pronouncement if you will as a result of which her public verification key which is her identity in the Bitcoin system is now bound to that transaction.
But what Bob doesn't know yet even though he knows all of these things and he can validate them what Bob doesn't know yet is whether Alice try to, let's say, previously signed or assigned those exact same coins to somebody else like maybe there's another party, let's say, you know, Alice has a friend named Eve, okay, maybe Alice decided she's going to send these Bitcoins not only to Bob but also she can try to send these same Bitcoins to Eve.  And Bob at this point may not have the assurance that Alice has not try to engage in these types of shenanigans, all right.
And so the tricky part here is that even though all the transactions we've talked about have been made public because Bitcoin requires all transactions to be made public, we still need a mechanism and this has to be a decentralized mechanism that does not require a trusted third party per se, we need a decentralized mechanism for agreeing really on the order in which transactions actually took place so that we can resolve any disputes about someone trying to double spend their coins, okay.  And it's that, that requirement, that timestamp that decentralized timestamp if you will which is where Bitcoin miners play a very important role in the Bitcoin ecosystem.  And I'll talk about how that works and how we deal with transaction time stamping in subsequent videos.