Skip to content

Transaction Details


Bitum transactions are transfers of BITUM that exist within blocks. Transactions are comprised primarily of inputs and outputs, though they have a few other fields of data as well.

Transaction Format

Field Description Size
Version Transaction version. This number is used to signify how the transaction should be interpreted. The upper 16 bits specify the serialization format and the lower 16 bits specify the version number. 4 bytes
Input count The number of inputs in the transaction encoded as a variable-length integer 1-9 bytes
Inputs Serialized list of all the transaction’s inputs Variable
Output count The number of outputs in the transaction encoded as a variable-length integer 1-9 bytes
Outputs Serialized list of all the transaction’s outputs Variable
Lock time The time when a transaction can be spent. (usually zero, in which case it has no effect) 4 bytes
Expiry The block height at which the transaction expires and is no longer valid 4 bytes

Inputs

Inputs spend previously-made outputs. There are two types of transaction inputs: Witness and non-witness.

Non-Witness Inputs

A non-witness transaction input is a reference to an unspent output and a sequence number. A reference to an unspent output is called an “outpoint.” Outpoints have three fields:

Field Description Size
Transaction hash The hash of the transaction which contains the output being spent 32 bytes
Output index The index of the output being spent 4 bytes
Tree Which tree the output being spent is in. This is required because there is more than one tree used to locate transactions in a block. 1 byte

In addition to an outpoint, non-witness inputs contain a sequence number. This number has more historical significance than relevant usage; however, its most relevant purpose is to enable “locking” of payments so that they cannot be redeemed until a certain time.

Witness Inputs

A witness transaction input contains the data necessary to prove that an output can be spent. Witness inputs contain four fields of data:

Field Description
Value The amount of coins that the output being spent transfers.
Block height The height of the block containing the transaction in which the output being spent is located.
Block index The index of the transaction in which the output being spent is located.
Signature script length The length of the signature script as a variable-length integer
Signature script The script that satisfies the requirements of the script in the output being spent.

Outputs

Outputs are transfers of BITUM that can be spent by inputs. Outputs always have three fields of data:

Field Description Size
Value The amount of BITUM being sent by the output. 8 bytes
Version The version of the output. This number is used to signify how the output should be interpreted. 2 bytes
Public key script The script that must be satisfied to spend the output Variable

Serialization

The format displayed above is not the format that transactions are sent and received in. When sending or receiving transactions, they can be serialized in a few ways. The way that a transaction should be deserialized can be determined from its version. Transaction versions occupy four bytes, but those four bytes are actually used to store two separate values. The first two bytes of a transaction’s version denote its actual version number. The second two bytes denote its serialization format.

Serialization Formats

When serializing, there are two main parts of a transaction: Its “prefix” and its witness data. The transaction prefix is comprised of:

  • Inputs (without any witness data)
  • Outputs
  • Lock time
  • Expiry

The witness data of a transaction involves only its inputs. The included data fields of its inputs depend on the specific serialization format. This format can be any one of the following:

  • 0 (Full serialization) - The transaction’s prefix is located immediately before its witness data.
  • 1 (No witness) - The transaction’s prefix is the only data present.
  • 2 (Only witness) - The transaction’s witness data is the only data present. For each input, this includes its value, block height, block index, and signature script.

Example Transaction

Below we examine an example transaction from the Bitum mainnet.

Raw Transaction (Hex)

Here is the raw hex data for the example transaction.

01000000024ff28b534361e383b5b149df4572feb1fbc659cb07067c3cb6c684452ae79f540100000000ffffffffc619e6ade3f469b8bb60b8ae9b0599eeeca05cd2db251cadea443344eafdac570100000000ffffffff0291c2e26d0200000000001976a914f2ccddc70f8b8bcea24a362bf404841d53cbebc088acd676dd680100000000001976a9141a1f5c7e9f7696989dced5cb9b61464f95790b7288ac000000000000000002ca68865402000000a29c0400040000006a4730440220139466bd10b1f071f9b4ac16ed434d63d090613fd06470f7bca9bba2b6ea6a0a02203cad1297ab9384466b3f304cd61e7e4ffa9abc1ae9fe1630207fae6f200da1680121024d540859b805c5780f2f0da350df8757c1defb72e3381b252d20874478a5549c49743a82010000009e9c0400010000006b483045022100da5b0fde58c4c57a88d96f83b02eddcb67b1b68ce95cc562c895f2e4e57bb44302201a8744aed654d2979bdd797187f6bf63ad1898c5d5c585309eeca558742858b201210307e3d98b004b15561c0f5aa158c90f93de33756d3bfd1f8a1058a4d90ffc7ec7

Transaction Breakdown

Below is a breakdown of the above raw hex transaction data into fields. This transaction uses the full serialization format, so we can see witness data along with inputs and outputs.

Field Value Description
Version 01 1
Serialization format 00 Full serialization
Number inputs 000002 2
1st input
Transaction hash 4ff28b534361e383b5b149df4572feb1fbc659cb07067c3cb6c684452ae79f54
Output index 01000000 1
Tree 00 0
(regular transaction tree)
Sequence number ffffffff 4294967295
(transaction finalized)
2nd input
Transaction hash c619e6ade3f469b8bb60b8ae9b0599eeeca05cd2db251cadea443344eafdac57
Output index 01000000 1
Tree 00 0
(regular transaction tree)
Sequence number ffffffff 4294967295
(transaction finalized)
1st output
Output amount 91c2e26d02000000 104.33512081
Script Version 0000 0
Public key script length 19 25
Public key script 76a914f2ccddc70f8b8bcea24a362bf404841d53cbebc088ac OP_DUP OP_HASH160 f2ccddc70f8b8bcea24a362bf404841d53cbebc0 OP_EQUALVERIFY OP_CHECKSIG

(Pay-To-Pubkey-Hash (P2PKH)
script)
2nd output
Output amount d676dd6801000000 60.54311638
Script Version 0000 0
Public key script length 19 25
Public key script 76a9141a1f5c7e9f7696989dced5cb9b61464f95790b7288ac OP_DUP OP_HASH160 1a1f5c7e9f7696989dced5cb9b61464f95790b72 OP_EQUALVERIFY OP_CHECKSIG

(Pay-To-Pubkey-Hash (P2PKH)
script)
Lock time 00000000 0
(no lock time)
Expiry 00000000 0
(no expiry)
Number witnesses 02 2
1st witness
Input amount ca68865402000000 100.08029386
Block height a29c0400 302242
Block index 04000000 4
Signature script length 6a 106
Signature script 4730440220139466bd10b1f071f9b4ac16ed434d63d090613fd06470f7bca9bba2b6ea6a0a02203cad1297ab9384466b3f304cd61e7e4ffa9abc1ae9fe1630207fae6f200da1680121024d540859b805c5780f2f0da350df8757c1defb72e3381b252d20874478a5549c The signature script contains two
pieces of data to be pushed onto
the stack:

1st push
(DER signature)
30440220139466bd10b1f071f9b4ac16ed434d63d090613fd06470f7bca9bba2b6ea6a0a02203cad1297ab9384466b3f304cd61e7e4ffa9abc1ae9fe1630207fae6f200da16801

2nd push
(public key)

024d540859b805c5780f2f0da350df8757c1defb72e3381b252d20874478a5549c
2nd witness
Input amount 49743a8201000000 64.79836233
Block height: 302238 9e9c0400 302238
Block index: 1 01000000 1
Signature script length 6b 107
Signature script 483045022100da5b0fde58c4c57a88d96f83b02eddcb67b1b68ce95cc562c895f2e4e57bb44302201a8744aed654d2979bdd797187f6bf63ad1898c5d5c585309eeca558742858b201210307e3d98b004b15561c0f5aa158c90f93de33756d3bfd1f8a1058a4d90ffc7ec7 The signature script contains two
pieces of data to be pushed onto
the stack:

1st push
(DER signature
3045022100da5b0fde58c4c57a88d96f83b02eddcb67b1b68ce95cc562c895f2e4e 57bb44302201a8744aed654d2979bdd797187f6bf63ad1898c5d5c585309eeca558742858b201

2nd push
(public key)

0307e3d98b004b15561c0f5aa158c90f93de33756d3bfd1f8a1058a4d90ffc7ec7