How Do Bitcoin Transactions Actually Work?

Whether you’re curious about becoming a developer for blockchain applications, or you’re just looking to know what happens under the hood once you send bitcoin to a lover , it’s good to possess a working knowledge of what happens once you create and broadcast Bitcoin transactions to the Bitcoin network. Why?

Because transactions are a basic entity on top of which the bitcoin blogockchain is made . Transactions are the results of an excellent collision of cryptography, data structures, and straightforward non-turing-complete scripting. They’re simple enough that common transaction types aren’t overly-complex, but flexible enough to permit developers to encode fairly customized transactions types also . Today we’ll take a tour of the previous .

As a developer, how does your bitcoin client post a replacement transaction to the network (and what happens when it’s received)?

What exactly is occurring once you send some bitcoin to a friend?

This post will assume that the reader features a basic understanding of hashing, asymmetric cryptography, and P2P networking. It’s also an honest idea to possess an honest sense for what exactly a blockchain is, albeit you’re unacquainted any specific mechanics.

Bitcoin Transactions and their role within the bigger picture

Bitcoin is comprised of a couple of major pieces: nodes and a blockchain. The role of a typical node is to take care of its own blockchain version and update it once it hears of a “better” (longer) version. Simply put, the blockchain has blocks, and blocks have transactions.

With this simplified but accurate picture in mind, you would possibly be wondering what exactly a transaction is formed out of.

How will understanding transactions help me to become a far better blockchain developer?

How do transactions allow me to transfer some bitcoin to a friend?

It seems that the answers to those questions vary supported many things. Even assuming that we’re talking only bitcoin, we will use transactions during a number of creative ways to accomplish a spread of personalized goals. Let’s start at the start , that is, let’s take a glance an honest old-fashioned pay-to-PK-hash transaction type. After all, this sort of transaction accounts for over 99% of all transactions on the bitcoin blockchain.



First, let’s build a mental model. It’s tempting to consider bitcoin as an account-based system. After all, once I send bitcoin to somebody, that person receives money and I’m left with a remaining balance. within the world though, things are represented a touch differently. Generally speaking, once I send money to somebody i'm sending spending all of that cash (minus transaction fees). a number of that cash are going to be spent back to my very own personal account if there exists a remaining balance. the purpose is that each one of the cash moves every single time. you'll skip to section 3.1 of for an evidence of why this model is preferable.



With that in mind, we will generalize and say that a bitcoin transaction has some inputs and outputs. A graphical representation might look something like this:

How Do Bitcoin Transactions Actually Work?

Save

How Do Bitcoin Transactions Actually Work?

This was somewhat confusing to me once I first saw it, so I’ll elaborate a touch . once I post a transaction, I’m essentially “claiming” an output and proving that I even have permission to spend the quantity of cash at that output. So if I’m Bob and that i want to pay Alice, those inputs are my proof that I even have been given a particular amount of cash (although this might just be some of my total balance), and therefore the outputs will correspond to Alice’s account. during this simple case, there would be only one input and one output.

A deeper check out Bitcoin transactions

Let’s understand the mechanics of a true bitcoin transaction. We’ll use the image above as a reference.

If you were to chop open a typical bitcoin transaction, you’d find yourself with three major pieces: the header, the input(s), and therefore the output(s). Let’s briefly check out the fields available to us in these sections, as they’ll be important for discussion. Note that these are the fields that are during a so-called raw transaction. Raw transactions are broadcast between peers when a transaction is made .

The Header

hash: The retrograde this complete transaction. Bitcoin generally uses hash values both a pointer and a way to see the integrity of a bit of knowledge . We’ll check out this more within the next section.
ver: The version number that ought to be wont to verify this block. the newest version was introduced during a soft fork that became active in December 2015.
vin_sz: the amount of inputs to the present transaction. Similarly, vout_sz counts the amount of outputs.
lock_time: We’ll check out this more in later articles, but this basically describes the earliest time at which a block are often added to the blockchain. it's either the block height or a unix timestamp.

Input

previous output hash: this is often a hash pointer to a previously unspent transaction output (UTXO). Essentially, this is often money that belongs to you that you simply are close to spend during this transaction.
n: An index into the list of outputs of the previous transaction. this is often the particular output that you simply are spending.
scriptSig: this is often a spending script that proves that the creator of this transaction has permission to spend the cash referenced by 1. and 2.

Output

value: the quantity of Satoshi being spent (1 BTC = 100,000,000 Satoshi).

scriptPubKey: The second of two scripts provided during a bitcoin transaction, which points to a recipient’s hashed public key. More on this in the last section of this article.

Transaction verification

One of the roles of a bitcoin node is that the verify that incoming transactions are correct (data hasn’t been tampered with, money isn’t being created, only intended recipients spend UTXOs, etc). A more exhaustive list can be found online, but I’ll list out a few of the important ones here:

All outputs claimed by inputs of this transaction are within the UTXO pool. Unspent outputs can only ever be claimed once.

The signatures on each input are valid. More precisely, we’re saying that the combined scripts return true after executing them one after the other. More on this in the last section.

No UTXO is spent quite once by this transaction. Notice how this is different than the first item.

All of the transaction’s output values are non-negative.

The sum of this transaction’s input values is greater than the sum of its output values. Note that if the numbers are different, the difference is taken into account to be a transaction fee which will be claimed by the miner.

A basic pay-to-PK-hash transaction

Bitcoin has its own custom (Forth-like) scripting language that's powerful enough to permit developers to make complicated and custom sorts of transactions. There are five or so standard transaction types that are accepted by standard bitcoin clients [5], however, there exist other clients that will accept other types of transactions for a fee. We’ll just cover the mechanics of pay-to-PK-hash here.

For any transaction to be valid, a combined scriptSig/scriptPubKey pair must evaluate to true. More specifically, a transaction spender provides a scriptSig that's executed and followed by the scriptPubKey of the claimed transaction output (remember how we said inputs claim previous unspent transaction outputs?). Both scripts share the same stack.

In the interest of efficiency, let’s use (official bitcoin wiki) a reference as we discuss. When you visit the link, set about halfway right down to find a table containing 7 rows. This table shows how the scripts are combined, how execution occurs, and what the stack seems like at each step.

One thing to notice is that, because bitcoin addresses are literally hashes (well, it gets even a touch more complicated. See ), there's no way for the sender to understand the particular public key to see against the private key. Therefore, the Redeemer specifies both the public key and private key, and the scriptPubKey will duplicate and hash the public key to make sure that the Redeemer is indeed the intended recipient.

 During execution, you'll see that constants are placed directly onto the stack once they are encountered. Operations add or remove items from the stack as they're evaluated. For example, OP_HASH160 will take the highest item from the stack, and has it twice, first with SHA-256 then with RIPEMD-160. When all items in our script are evaluated, our entire script will evaluate to true if true remains on the stack, and false otherwise.

All in all, the pay-to-PK-hash may be a pretty straightforward transaction type. It ensures that only a redeemer with the acceptable public/private key pair can claim and subsequently spend bitcoin. Assuming that all other criteria are met (see the previous section), then the transaction is a good one and it can be placed into a block.

In future articles, I’ll break down more complicated types of transactions. We’ll see how more than two parties can participate in a transaction, and we’ll see how longer-running transaction types can be implemented.