Introduction

Transactions are the heart of Bitcoin and the only purpose of blockchain is to store transactions in a secure and reliable way, so no one could modify them after they are created. Today we’re starting implementing transactions. But because this is quite a big topic, I’ll split it into two parts: in this part, we’ll implement the general mechanism of transactions and in the second part we’ll work through details.

Also, since code changes are massive, it makes no sense describing all of them here. You can see all the changes ​​here​​.

There is no spoon

If you’ve ever developed a web application, in order to implement payments you would likely to create these tables in a DB: ​​accounts​​ and ​​transactions​​. An account would store information about a user, including their personal information and balance, and a transaction would store information about money transferring from one account to another. In Bitcoin, payments are realized in completely different way. There are:

  1. No accounts.
  2. No balances.
  3. No addresses.
  4. No coins.
  5. No senders and receivers.

Since blockchain is a public and open database, we don’t want to store sensitive information about wallet owners. Coins are not collected in accounts. Transactions do not transfer money from one address to another. There’s no field or attribute that holds account balance. There are only transactions. But what’s inside a transaction?

Bitcoin Transaction

A transaction is a combination of inputs and outputs:

type Transaction struct {
  ID   []byte
  Vin  []TXInput
  Vout []TXOutput
}

Inputs of a new transaction reference outputs of a previous transaction (there’s an exception though, which we’ll discuss later). Outputs are where coins are actually stored. The following diagram demonstrates the interconnection of transactions:

GO语言实现区块链Part4 Transactions 1_ide

Notice that:

  1. There are outputs that are not linked to inputs.
  2. In one transaction, inputs can reference outputs from multiple transactions.
  3. An input must reference an output.

Throughout this article, we’ll use words like “money”, “coins”, “spend”, “send”, “account”, etc. But there are no such concepts in Bitcoin. Transactions just lock values with a script, which can be unlocked only by the one who locked them.

Transaction Outputs

Let’s start with outputs first:

type TXOutput struct {
  Value        int
  ScriptPubKey string
}

Actually, it’s outputs that store “coins” (notice the ​​Value​​ field above). And storing means locking them with a puzzle, which is stored in the ​​ScriptPubKey​​. Internally, Bitcoin uses a scripting language called Script, that is used to define outputs locking and unlocking logic. The language is quite primitive (this is made intentionally, to avoid possible hacks and misuses), but we won’t discuss it in details. You can find a detailed explanation of it ​​​here​​.

In Bitcoin, the value field stores the number of satoshis, not the number of BTC. A satoshi

Since we don’t have addresses implemented, we’ll avoid the whole scripting related logic for now. ​​ScriptPubKey​​

By the way, having such scripting language means that Bitcoin can be used as a smart-contract platform as well.

One important thing about outputs is that they are indivisible, which means that you cannot reference a part of its value. When an output is referenced in a new transaction, it’s spent as a whole. And if its value is greater than required, a change is generated and sent back to the sender. This is similar to a real world situation when you pay, say, a $5 banknote for something that costs $1 and get a change of $4.

Transaction Inputs

And here’s the input:

type TXInput struct {
  Txid      []byte
  Vout      int
  ScriptSig string
}

As mentioned earlier, an input references a previous output: ​​Txid​​ stores the ID of such transaction, and ​​Vout​​ stores an index of an output in the transaction. ​​ScriptSig​​ is a script which provides data to be used in an output’s ​​ScriptPubKey​​. If the data is correct, the output can be unlocked, and its value can be used to generate new outputs; if it’s not correct, the output cannot be referenced in the input. This is the mechanism that guarantees that users cannot spend coins belonging to other people.Again, since we don’t have addresses implemented yet, ​​ScriptSig​​Let’s sum it up. Outputs are where “coins” are stored. Each output comes with an unlocking script, which determines the logic of unlocking the output. Every new transaction must have at least one input and output. An input references an output from a previous transaction and provides data (the ​​ScriptSig​​

But what came first: inputs or outputs?

The egg

In Bitcoin, it’s the egg that came before the chicken. The inputs-referencing-outputs logic is the classical “chicken or the egg” situation: inputs produce outputs and outputs make inputs possible. And in Bitcoin, outputs come before inputs.

When a miner starts mining a block, it adds a coinbase transaction

As you know, there’s the genesis block in the beginning of a blockchain. It’s this block that generates the very first output in the blockchain. And no previous outputs are required since there are no previous transactions and no such outputs.

Let’s create a coinbase transaction:

func NewCoinbaseTX(to, data string) *Transaction {
  if data == "" {
    data = fmt.Sprintf("Reward to '%s'", to)
  }

  txin := TXInput{[]byte{}, -1, data}
  txout := TXOutput{subsidy, to}
  tx := Transaction{nil, []TXInput{txin}, []TXOutput{txout}}
  tx.SetID()

  return &tx
}

A coinbase transaction has only one input. In our implementation its ​​Txid​​ is empty and ​​Vout​​ equals to -1. Also, a coinbase transaction doesn’t store a script in ​​ScriptSig​​. Instead, arbitrary data is stored there.

In Bitcoin, the very first coinbase transaction contains the following message: “The Times 03/Jan/2009 Chancellor on brink of second bailout for banks”. ​​You can see it yourself​​.

​​subsidy​​ is the amount of reward. In Bitcoin, this number is not stored anywhere and calculated based only on the total number of blocks: the number of blocks is divided by ​​210000​​. Mining the genesis block produced 50 BTC, and every ​​210000​​