Finance and capital markets
- Bitcoin: What is it?
- Bitcoin: Overview
- Bitcoin: Cryptographic hash functions
- Bitcoin: Digital signatures
- Bitcoin: Transaction records
- Bitcoin: Proof of work
- Bitcoin: Transaction block chains
- Bitcoin: The money supply
- Bitcoin: The security of transaction block chains
The basic mechanics of a bitcoin transaction between two parties and what is included within a given bitcoin transaction record. Created by Zulfikar Ramzan.
Want to join the conversation?
- At7:25, why must alice spend all of her coins and ask for some back? Why can't she just send the correct amount (50, in this case)?(33 votes)
- She only has 3 inputs: 25, 20 and 20. They must all be spent or else there would be less than 50 which she wants to send. Each input can only be spent once, so she spends all of them, and gives 50 to Bob and 14 back to herself. The 1 BTC left over is given to the miner as a fee. If she didn't give the 14 BTC back to herself, then all 15 BTC would be give to the miner.(33 votes)
- what if no Bitcoins are assigned to the miner for the transaction. Could it happen that the transaction isn't processed by any of the miners? If so, what happens to the Bitcoins assigned to the attempted transaction? .. will they be in limbo forever? Can the transaction be cancelled if it isn't being processed by the miners?(14 votes)
- Yes. I've tried it once before. Most wallets will stop broadcasting such transaction after some time and return it to the sender.
If the transaction's OUTPUT is <0.01BTC, and no transaction fee is added, the transactions will probably never verify.(6 votes)
- How do the digests of the previous transactions (D_C, D_D and D_T) guarantee that those transactions really took place? What if Alice just makes up a transaction that never happened (such as 10000 <-> VK_E) and includes it?(6 votes)
- Bitcoin miners have the entire record of all transactions, so when they receive a new transaction they check that the inputs to the new transaction are valid outputs of previous transactions and that the inputs have not been spent already. Miners will ignore transactions that don't meet the requirements.
If there was a bad miner that decided to include a bad transaction in a block, then the other miners would detect the invalid transaction in the block and ignore the block.(16 votes)
- Maybe getting ahead of the series here, but it's not ACTUALLY typical that a transaction sends bitcoins to a verification key directly. It is sent to a (RIPEMD) HASH of a verification key (confusingly). It's not until Bob actually spends the output, that he reveals his verification key. Perhaps a future video could explain this as well as the virtual machine that executes to verify transactions and allow for more complex types of transactions than simple A->B transfers.
Another nit - I believe Alice's signature appears once per input in a transaction - not one for the whole transaction block.(3 votes)
- Thank you for point this out. Tou are absolutely correct. I was loose in terms of what an actual bitcoin identifier is (i.e., hash of a public key vs. public key). I glossed over this detail to keep things simple since in terms of the higher level architecture/mechanics, how the identities are passed isn't so material (as long as there is a way to figure out who the transaction is meant for). I also left out the index field in the input and the FORTH-like Script since it's hard enough to understand the most basic bitcoin use case, let alone some of the other more complex cases. Once someone gets a handle on the core part of bitcoin, my thinking is that it is easier to see how these enhancements can be folded in.(14 votes)
- If a miner must review the entire blockchain to validate that Alice has the bitcoins she represents, then how can this be done in a timely way as the blockchain gets bigger and bigger ... Ultimately won't there be a scaling problem as the number of transactions and length of the blockchain becomes extremely large?(7 votes)
- Each node keeps an index of unspent transaction outputs. When a new transaction or block comes in that index is referenced to find the appropriate transaction referenced by the transaction inputs. When a new transaction is accepted the transaction outputs that it spends can be removed from the index. Accordingly it only has to track the unspent set not every transaction in the block chain. That said as it is today the whole block chain must be downloaded. But there is work under way to fix this. https://bitcointalk.org/index.php?topic=204283.0(4 votes)
- The transaction block chain has to be stored somewhere. Will it not become insanely large over time? Where do miners store the chain? How is it searched?(5 votes)
- Miners would tell every node on the network about their new blocks, and each node will then store the blockchain on their own hard drive. The bitcoin blockchain right now is about 80 GB, which is insanely large indeed, but not all nodes need to store the whole chain, but only the last few blocks.(4 votes)
- If I buy a single Bitcoin in 2013 and decide to save it for 100 years, will it expire? Will the 2113 transaction force miners to retain that transaction record from 2013? It seems my coin is dependent on my client software allowing me to spend it and miners accepting the transaction. Is there a way to backup my coin?
- There is no expiration date.
Yes, your transaction entry is always a part of the "chain."
Coins are associated with bitcoin wallets, so the way to back it up is to keep a copy of your wallet ID number.(4 votes)
- Are miners people or automated software on a computer?
What if we have a transaction fee of 1 Bitcoin can 2 miners verify the transaction? Does each minor get half of the Bitcoin transaction fee?(4 votes)
- Miners are people who are using tools to mine bitcoins. Those tools are automated software and miners basically just sit and watch their bitcoins increase (sitting and watching is not mandatory).
The process of how two miners verifying the transaction at the same time is resolved is talked about in the Bitcoin: Transaction block chains video.
In short the miner that provides the most resource consuming (least statistically likely) proof will prevail and get all transaction fees. In reality the miners tend to create groups called pools and share all of their income in the group based on the amount of work done by their computers. This is done to get steady bitcoin income, working alone to get any success might take a year or longer.(2 votes)
- Does it have to be a transaction fee for the miner? Wouldn't it work without it? And who decides how high is the transaction fee or how is it calculated?(1 vote)
- Bitcoin miners act like auditors in the bitcoin system by adding transaction (blocks) to the transaction block chain (thereby legitimizing the chain). They currently have two incentives for engaging in the effort required to add transactions to transaction block chains: (1) They are rewarded a number of bitcoins if they succeed in getting transaction blocks added to the transaction block chain (25 bitcoins at the present time -- May 2013 -- and going down by half approximately every four years); (2) They are paid a transaction fee. Eventually the bitcoin reward will be zero (or at least close enough to 0 where it will not be a sufficient incentive). In this case, the miners need some incentive to carry on with the mining effort. The hope is that transaction fees will be enough incentive. The transaction fee is actually set by the party in the transaction that currently owns the bitcoin. In the running example given in the videos, this party would be Alice. Alice lists what fee she is willing to pay. This fee is specified implicitly; in the implementation, Alice has to specify the incoming transactions (i.e., the inputs) and the outgoing transactions (i.e., how much she'd like to give to Bob and other parties and how much change she wants for herself). Whatever remains unaccounted for becomes the transaction fee. Alice needs to set the fee appropriately so that bitcoin mining nodes have an incentive to proceed. If the fee is set to 0, then bitcoin miners may simply choose to ignore the transaction. On the other hand, Alice may not need to set the fee too high since bitcoin miners will get paid the sum of all the transaction fees in the block of transactions that they added to the chain. And the marginal computational cost of having extra transactions in the block is relatively small (the heavy lifting is in finding the proof of work). If Alice sets the fee really high, then nodes in the bitcoin network that have a lot of dedicated computational power might clamor to add the transaction. If the fee is set really low, then these nodes might not be as interested -- but then perhaps some of the less computationally powerful nodes will step up. It's not clear what will happen in this scenario and how it will play out -- but it will definitely be interesting to see how it evolves.(8 votes)
- How would you acquire your very first bitcoin?(2 votes)
Voiceover: At its core, bitcoin is just basically a chain of digital signatures that really reflect the coin's path through the bitcoin ecosystem. And, you know what? 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 the 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. In this context, you can think of a transaction as just a digitally-signed declaration by one party of its intent to transfer some bitcoins that they possess 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 transactions 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? Now, I realize it's 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. 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, and let's say she would like, has an intention of wanting to transfer 50 bitcoins to Bob. 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 that actually corresponds to a public verification key for a digital signature scheme. So, in this case, let's say Alice's identity in the system is really some public verification key, which we'll call VK of A, so Alice's verification key, and in the context of Bob, let's say his public verification key is VK sub 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 to 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 who's 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 signing key in this context, SK of Alice, and we'll say that Bob's signing key is SK of Bob. Okay? And they're going to basically keep these keys private. Now let's say that Alice herself had received in the past, three transactions of bitcoins from other parties. Let's say she got 25 bitcoins from Carol, and we'll call Carol VK of C to associate that with her key, let's say she got 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 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, these will have been recorded in the bitcoin ecosystem, so 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 as 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, in 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 transaction. So in this case, let's say she has a digest that corresponds to the transaction of 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 what these [trackers] 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 these different transaction records, and they can verify that these cryptographic hashes, when applied to those transaction records provide you back with the values 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 functions, we have a cryptographic guarantee that, 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? Because we're using cryptographic hash functions, 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 a line so 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 transaction so that anybody can verify that she possessed these coins. You can think of this part of the transaction, really, as representing the input, the input to 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, and so for starters, in the output portion, she has to include, or Alice has to include a list of recipients for her bitcoins, 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 you mentioned earlier was Bob's public key, so we'll say that she'll mention V sub K of B, and she also has to record and mention at this stage how many coins she wants to transfer to Bob and as we 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 of 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 back change because she has 65 bitcoins kind of coming in, and she is only giving 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 change, 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 transaction data, this input and this output, and she's going to digitally sign that data, and she's going to use her signing key, her signing 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'll effectively bind Alice's identity with the transaction record itself. 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 the signature that corresponds to her public key because she's the only person who, in theory, should possess the private signing 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. Everybody in the bitcoin network will basically know now that VK sub A is trying to send 50 bitcoins to VK sub B. Now, at this point, you may have noticed a slight discrepancy here that Alice started off with 65 coins, 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. So there's this issue, what happens with this one, 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 basically saying that this one leftover coin should be provided as transaction fee to what's known as a bitcoin miner. A bitcoin miner, as I mentioned in a previous video, is 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? Well, 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 publically announced her intention to transfer some of the bitcoins to Bob, but she digitally signed 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 tried to, let's say, previously sign, or sign those exact same coins to somebody else. Maybe there's another party. Let's say Alice has a friend named Eve. Maybe Alice decided she's going to send these bitcoins not only to Bob, but also she's going to try to send these same bitcoins to Eve, and Bob at this point may not have the assurance that Alice has not tried 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 the 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. It's that requirement, that timestamp, that decentralized time stamp, 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.