How Bitcoin transactions work

How Bitcoin transactions work

July 16, 2017 Cyrus.Sh Cryptograhpy

Introduced in 2009, bitcoin appeared as the most remarkable digital cryptocurrecy. The theory behind bitcoin is to how to send some amount of money to someone directly without the need for any intermediary and in a secure manner which both guarantees the integrity of the payment data and its authorization. Unfortunately the official documents are difficult for many people and developers who are not familiar with the concept. In this post, with a simple literature I tried to clarify bitcoin transactions as simple as possible. It is expected the reader would assimilate the exact idea behind bitcoin transactions and authorization system after reading the post thoroughly . So please read till the end of if you are interested.

Bitcoin transactions use a peer-to-peer system to transfer digital coins. It may be interesting to know there is actually not any records of the coins stored anywhere. In fact there is no coin! These are the transactions that specify how much bitcoin each person has. Transactions are chained together in a manner that makes it nearly impossible for an attacker to manipulate any part of what we know as the block chain. A new block is added to the whole blockchain after mining new bitcoins, but in this article we only focus on how an individual sends some specified amount of bitcoin to another.

Let’s start simple. Consider a payment system named arbitrarily LockCoin. We use LockCoin as an analogy with the real bitcoin transactions.
We have Alice here who wants to send some money to Bob. This is the scenario to send this money in a way that only Bob and no one else would be able to get the money and use it:

Alice has a magic safe (we are talking here about physical money and safe not digital!) and the safe has been magically designed in a way that after someone puts some money inside it, it can only be opened by the key of the recipient of that money. Anybody else may have their own key but none of them can access the money inside the safe except the recipient.Bob receives the money and since the money is actually destined to him, he can open the safe by his private key and access the money.Now if Bob wants to send this money to someone else, the money goes through same stages; he puts the money inside the safe and closes it. The safe remains closed until the true recipient of the money inside arrives with his personal key!

Figure below depicts this scenario; only the specific key whose owner is the recipient can open the safe:

The idea behind a transaction in bitcoin system is more or less the same; only the valid user will be able to spend the amount of bitcoin another party previously has sent to him. To understand how this is possible, you should see the way a transaction is structured. That is understanding the format of a transaction and the steps involved for verifying it. First let’s look at a transaction different parts.

The two main elements of a transaction are input and output. We may have more than one output in each transaction; i.e. we can send bitcoins to multiple parties. For the sake of simplicity we only consider a transaction with one input and one output then you can do some inferring yourself to understand how other cases work. Outputs of a transaction are indexed starting from zero, thus for our example the output index is always 0 since we only have one output in the transaction.
A transaction is spending an old output, creating a new output.
This is the general structure of a single such transaction:

TXID: Every transaction has a unique ID to be identified among other transactions. Remember a transaction is shown as TX and we will use this abbreviation later.A TXID referring to a previous transaction whose output is gonna be spent. We call it oldTXVOUT: The output index of the output in oldTX which as stated before is 0.ScriptSig: Explained shortlyAmount of bitcoin to deliver to the party. This must be less than or equal to the output’s amount in oldTX. This is the amount of the new output. We suppose it to be equal to the amount of the output of oldTX. i.e we are going to spend all of the output of oldTX.ScriptPubKey: Conditions to authorize spending the new transaction in future. This is explained in more details shortly.VOUT: Again 0The receiver bitcoin address. (Explained shortly)

The most remarkable parts are bitcoin address, ScriptSig, scriptPubKey

Bitcoin Address:

Each party participating in the transaction procedure has a key pair used in public key cryptography which establishes the main security and integrity aspects of cryptocurrencies. Public key encryption as opposed to symmetric encryption uses two keys instead of one for encryption/decryption processes. A bitcoin address is the hashed version of one’s public key. Each person who’s going to request payment and provide others with a means to send him money, delivers his bitcoin address using which others can send him bitcoin.
Bitcoin uses Elliptic Curve Digital Signature Algorithm and as previously introduced, the system calculates the hash of the public key before publishing it. This has two main benefits:
1. The hash is transformed to another shorter string using base58 encoding algorithm. The final string has only those ASCII characters which are less prone to human errors while reading them. For example it may have “1” but not “l”. The full characters allowed to be part of bitcoin address are as follows:

123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz

2. Using the calculations related to key generation in bitcoin protocol, if we have a private key we can deterministically derive the corresponding public key but the reverse is not possible so far. That is by having the public key, there is no solution yet to calculate the private key. But to make everything safer, bitcoin avoids disclosing the public key until the output is spent. This eliminates the chance of reconstructing the private key from public key in a possible future attack.

The sender of bitcoin needs to have receiver’s address to associate the output of transaction to the owner of the address.

An output with any specific address which is the hashed version of a public key can be spent by anyone who has the corresponding private key and no one else.

Here the public key is only a means for the receiver to prove he is the true and valid receiver. We will see how this is possible.

Now we need to remind you the definition of a transaction in bitcoin once again:

A transaction means spending a previously-made output of a previous transaction.

Each transaction has two fundamental parts: input and output

The input provides the proof to be the receiver of and spend an old output.
The output specifies the receiver of the transaction – or the receiver of the money which the transaction is made to deliver.

Look at the figure below. I tried to visualize what I mean by the few lines above. Suppose that Andy has already sent Alice some bitcoins. So transaction Andy->Alice is the old transaction here. Now Alice wants to spend the received bitcoins from the old transaction and send them to Bob.

As you can see we have TX1 (transaction number one which has been issued in a previous time by Andy) and TX2 (transaction number two which we want to create now to send same amount of bitcoins to Bob’s address specified in output2)
The input in TX2 is actually spending the money sent to Alice whose address is specified in output1. But in order to do this, Alice needs to prove she is the the one who Andy has actually sent the bitcoins to and consequently the owner of the bitcoins. Alice does this by using ScriptSig.

ScriptSig:

This is where the bitcoin system (the miners to be more specific) looks into to find the necessary items needed to prove the person who has the associated private key actually issued the new transaction. In fact Alice must have the corresponding private key to the public key of output1. And since she is really the person who Andy has sent the money to and she is the person that Andy used her public key to specify the sender, then she can compose a valid ScriptSig using her private key which satisfies the conditions available in scriptPubKey of TX1.

ScriptPubKey

Each output has a scriptPubKey part that specifies the receiver of the transaction. The receiver later needs to prove his authenticity using the ScriptSig of a future transaction he makes.

Now we need to see how scriptPubKey and ScriptSig are made and how they associate with each other.
Bitcoin system uses a scripting language to compose scriptPubKey and ScriptSig. This scripting language has its own syntax and opcodes and also uses a software simulated stack as its temporary memory. For a detailed explanation of this scripting language please refer to the related bitcoin wiki. We just explain how these two parts are made and used to verify a transaction which is enough to understand how transactions properly work.
scriptPubKey is defined as follows:

scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

Focus on the transaction you already saw in the figure above. Having Andy sent bitcoins to Alice, the scriptPubKey of TX1 would be something like this:

scriptPubKey: OP_DUP OP_HASH160 <Public Key Hash of Alice> OP_EQUALVERIFY OP_CHECKSIG

ScriptSig is simply the combination of the signature and the associated public key with the private key using which the signature has been made.

scriptSig: <signature> <Public Key>

Referring back to our example we have ScriptSig of TX2 like this:

scriptSig: <signature of Alice> <Public Key of Alice>

Okay. Now the system uses the script written in scriptPubKey of TX1 and ScriptSig of TX2 to verify the authenticity of the transaction sent by Alice. To do this it first pushes on the stack the contents of the ScriptSig (stack contents in line2 of the table below) then executes scriptPubKey one command at a time.

nStackScriptDescription1Empty.<sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIGscriptSig and scriptPubKey are combined.2<sig> <pubKey>OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIGConstants are added to the stack.3<sig> <pubKey> <pubKey>OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIGTop stack item is duplicated.4<sig> <pubKey> <pubHashA><pubKeyHash> OP_EQUALVERIFY OP_CHECKSIGTop stack item is hashed.5<sig> <pubKey> <pubHashA> <pubKeyHash>OP_EQUALVERIFY OP_CHECKSIGConstant added.6<sig> <pubKey>OP_CHECKSIGEquality is checked between the top two stack items.7trueEmpty.Signature is checked for top two stack items.

This is the process of verifying the transaction step by step:

OP_DUP: This duplicates the top entry of the stack which is pubkey of ScriptSig. See the result in line 3OP_HASH160: Calculates the hash of the top entry of the stack and removes the entry before pushing the hash onto the stack. See the result in line 4.Then pubKeyHash which was present in scriptPubKey of TX1 is pushed onto the stack. See the result in line 4OP_EQUALVERIFY: Compares the calculated Hash and pubKeyHash at top of the stack then removes both from the stack. Up to this point if the two aforementioned values are equal it is shown that the sender of TX2 has actually the public key whose hashed value existed in TX1 scriptPubKey. (Remember only the hashed version of one’s public key is published using the bitcoin address not the plain version) This is the point where the public key is disclosed and this is one of the reasons it is better not to use a same bitcoin address to receive bitcoin for more than once. See the result in line 6.OP_CHECKSIG: This is the final phase which the system goes through to check whether the sender is the Alice herself. This can be done by checking the signature -that Alice has made using her private key and is provided in ScriptSig of TX2- against the public key in the same ScriptSig. In theory there’s no difference what to sign to verify the a signature (having a signature and the public key giving that we know what has been signed is enough to verify a signature) but in bitcoin, the entire transaction is signed (except script parts) to not only verify the owner but also to make the transaction resistant against any modification by attackers. If the signature matches the public key then the transaction is valid.

If a transaction is verified without an error the new output becomes “An Unspent Transaction Output”; abbreviated as UTXO. Also note an output need not be sent totally to a single person and you can break it into parts sending to different parties. But we did not cover that since it’s not relevant to our purpose of writing this article. But in practice you can even spend only a part of a UTXO; sending a fraction of it to another person and receiving back the remainder in a new bitcoin address belonged to yourself. (For example if I have 1 bitcoin and want to send Bob 0.2 of it, I cannot keep the 0.8 of old output, the output must be spent altogether but instead I send 0.2 of it to Bob and send 0.8 of it to another one of my own addresses. This makes a valid UTXO with 0.8 a bitcoin worth amount sent to my bitcoin address along with an output specifying Bob as the receiver of 0.2 a bitcoin so that in future I can spend the former and Bob can spend the later.)

After the transaction of our example passes the verification, Bob would be able to spend the output of TX2 since he is now the owner of the output as long as he possesses his private key. I think you can simply relate this to the example of our hypothetical LockCoin system we proposed at the beginning of the post.

Feel free to contact me or write comments if any of these I’ve written here still seems vague to you.

Please donate