• en
    • it
    • ru
Type anywhere to search

Transactions are the most important part of the bitcoin system. All other elements of the system are
designed to ensure that transactions can be created, propagated in the network, and validated
finally added to the global transaction register (the blockchain). Transactions are data structures
which encode the value of transfer between participants in the bitcoin system. Each transaction is a
public data in the bitcoin blockchain, the double-entry global accounting register.
The life cycle of a transaction begins with its creation, also known as a generation. There
the transaction is then signed with one or more signatures indicating the authorization to spend the funds reported
from the transaction. The transaction is then transmitted on the bitcoin network, where each node of the network
(participant) valid and propagates the transaction until it reaches almost every node in the network.
Finally, the transaction is verified by a miner node and included in a transaction block that is
registered in the blockchain.
Once registered on the blockchain and confirmed by a sufficient number of successive blocks
(confirm), the transaction is a permanent part of the bitcoin register and is accepted as valid by all
participants. The funds allocated to the new owner by the transaction can be spent in one
new transaction, extending the chain of ownership steps and starting the life cycle again
of a transaction.
12A transaction can be created online and offline by anyone, even if the user who generates it can not
has the private key to sign the transaction.
Once created the transaction must be signed by the owner (or owners) of the funds spent in
it and if it has been correctly created and signed (contains all the information necessary to the
transfer of funds) can be transferred to the network and propagated between the nodes in order to achieve a
mining node that incorporates it into a block and adds it to the blockchain.
Since the transaction is signed and does not contain any confidential information, like
private keys or credentials, it can be published openly using any underlying network
for the transport of data that is convenient. Unlike credit card transactions, for
example, which contain sensitive information and can only be transmitted over protected networks, one
bitcoin transaction can be sent on any network in order to reach a bitcoin node that the
can propagate in the network.
Once a bitcoin transaction is sent to any node connected to the bitcoin network, that one
transaction will be validated by that node. If valid, that node will propagate it to the other nodes to which it is
connected, and a confirmation message will be synchronously returned to the source node. If the
transaction is invalid, the node will reject it and synchronously return a message of rejection to the node
The bitcoin network is a peer-to-peer network which has no fixed topology or default structure. A
any set of data to be transferred, whether they refer to a transaction or a block, is
propagated from a node to the network through the peers to which it is connected through a process of
propagation known as “flooding” (flooding). Therefore, the transaction originates in the node
source which transfers it through the TCP connections that it has established with the peers with which it is
Each receiving node carries out a transaction verification procedure and in the event that such verification occurs
having a positive outcome, it propagates the transaction by transferring it to the peers with whom it shares a connection
TCP. The flooding process allows the transfer of a valid transaction to the entire network within a period of
a few seconds.


Structure of transactions

A transaction is a data structure that encodes and transfers a value from a source of funds, called
input, to a destination, called output. Transaction inputs and outputs are not
related to no account or identity, but are simply currency units protected by one
secret key that only the owner, or the person who knows the key, can unlock.

Before proceeding with the discussion of the basic elements of a bitcoin transaction, we describe the
Locktime field structure.
The locktime, also known as nLockTime from the variable name used in the client
reference (reference client), defines the first time (timestamp) in which a transaction is
considered valid and can be transmitted to the network or added to the blockchain. It is set to
zero in many transactions to indicate propagation and immediate execution. If the locktime
has a value greater than zero and less than 500 million, is interpreted as a block height, this is a
mean that the transaction is not valid and will not be transmitted or included in the blockchain before
achievement of the specified block height. If the value is over 500 million, it is interpreted as a
Unix Epoch timestamp (seconds from midnight January 1, 1970) and the transaction will not be
valid before the specified time. Transactions with locktime that specify a future block or a
timestamps must be created by the originating system and transmitted to the bitcoin network only after that
they have become valid. Use of locktime is equivalent to posting a check.
The basic building blocks of a bitcoin transaction are unspent transaction outputs (unspent
transaction outputs) or UTXO. UTXO are indivisible fragments of bitcoin currency “locked” on
a specific owner, registered on the blockchain, and recognized as a unit of currency from around the
Whenever a user receives bitcoins, that sum is registered in the blockchain as UTXO.
Therefore, a user’s bitcoins could be scattered in UTXO in the thousands of transactions
contained in the thousands of blockchain register blocks. There is no balance related to an address
bitcoin or to an account but only UTXO disseminated, protected on specific owners. The concept of
a user’s bitcoin balance is a derived construct created by the wallet application. The wallet calculates the
user balance by scanning the blockchain and aggregating all the UTXOs belonging to that user.
A UTXO may have an arbitrary value denominated in multiples of satoshi (one hundred millionth part
of a bitcoin). Despite this, a UTXO can not be divided and every transaction that is
use as input it must spend it in its entirety. If the amount of currency in the UTXO
specific is greater than the amount of currency to be transferred the user who generates the transaction must attach
a remainder output (output directed to your bitcoin address with transferred value equal to the difference
between the amount of UTXO currency used as input and the amount of currency to be transferred
UTXOs consumed by a transaction are called transaction inputs, and le
UTXOs created by a transaction are called transaction outputs (transaction output). In this
way, a bitcoin value part moves forward from one owner to another in a chain of
transactions that consume and create UTXO. Transactions consume UTXO by unblocking them with the
signature of the current owner and create UTXO by blocking them on the bitcoin address of a new one
owner. The only transaction that does not need a UTXO type input is the coinbase transaction
which is used by the miners to obtain revenues related to the mining process of a block. In this
case the transaction input is represented by a newly created unit of currency and is not attributable to
no previous transaction (detailed treatment of coinbase transactions is present in the
mining process paragraph).
UTXOs are tracked by each full-node bitcoin client as a series of data called UTXO set or
UTXO pool, and saved in a database. New transactions consume (spend) one or more of these
output contained in the UTXO set.
The structure of a transaction output is shown in the figure below.

A transaction output associates a quantity of currency expressed in satoshi to a specific locking
script which defines the conditions that must be respected to spend this amount. In
in most cases, the locking script blocks the output on a specific bitcoin address for
transfer the amount of the transaction to a new owner.
The mirror element to the transaction output is transaction input.
A transaction input is a pointer to a UTXO, and consists of the transaction hash and the number
sequence of the transaction in which the UTXO is registered in the blockchain. In order to spend that
UTXO transaction input must also include the corresponding unlocking script, usually
represented by the signature of ownership attestation associated with the bitcoin address specified in the
locking script.
The structure of a transaction input provides a sequence number field, used for
overwriting a transaction before the transaction locktime expires, which is a function
currently disabled in bitcoin. Most transactions set this value to
maximum integer value (0xFFFFFFFF) so that it is ignored by the bitcoin network. If the transaction has
a non-zero locktime, at least one of its inputs must have a sequence number less than
0xFFFFFFFF to enable locktime.

Many transactions include commissions (fees) as an incentive to include (undermine) the
transaction in the next block and also to discourage “spam” or any type of transaction
16 abuse of the system, imposing a small cost on each transaction. Transaction fees are
credited to the miner who undermines the block and records the transaction on the blockchain.
Transaction fees are calculated based on the size in kilobytes of the transaction
and not the amount spent in the transaction itself. Transaction fees are one of the priority criteria
with which a mining node chooses the transactions contained in the transaction pool to be inserted into the
block that attempts to undermine. This entails that a transaction with a commission value
sufficient has a greater probability of being included in the next block validated and attached to
blockchain minimizing processing times of the transaction. Transactions without
commissions are still considered valid by the system but the mining nodes take to discard them
(since they do not contribute to the revenues received from the block validation process) and therefore the times
processing of these transactions extends indefinitely.
In general, the wallet application with which the transaction is generated provides for the calculation of the
commission for that specific transaction according to a series of parameters imposed by the system (the
transaction can still be created with alternative methods that do not support the calculation
automatic commission by delegating this task to the generating user).
In its first bitcoin implementation it provided a fixed commission value for each
network transaction. Over time the commission calculation process has evolved as well as the
how they affect the priority of processing a transaction. The current minimum value
of commission is 10 000 satoshi for each kilobyte. Applications are expected in the future
wallet can determine the fees to be associated with a transaction based on statistical parameters
of the network such as the average commission value for the most recently approved transactions e
additions to the blockchain.
The data structure of a transaction does not include a commission field, it is represented by the
difference between the total currency contained in the transaction inputs and the total currency contained in the
transaction output. In this regard it is important to include in each transaction the eventual output of
direct transaction to your bitcoin address for the “rest” avoiding that the difference between the UTXO of
input and the output value to be transferred is interpreted as a commission for the transaction.
As we have seen, transactions form a chain in which every transaction spends the output of
transaction of the previous transaction (known as a parent transaction) and creates input for the transaction
next (known as a daughter transaction). Sometimes transactions in a chain of dependent transactions
among them are created simultaneously to allow a complex system of transactions that
requires valid child transactions to be signed before the parent transaction is signed (this is the case of the
CoinJoin transactions in which multiple users share the same transaction to protect their own
privacy and not to share sensitive information with the network such as the flow of currency between addresses of
When an entire transaction chain is propagated in the network the individual component transactions
they could be received by a node asynchronously (the order of transactions in the chain does not
corresponds to the order of receipt of the same) and, therefore, a child transaction can be received
before the corresponding mother transaction. System policies do not allow propagation
in the network transactions that contain transactional input referring to the output of unknown transactions. For
guarantee the correct functioning of the most complex systems of transaction generation each
node preserves orphan transactions (transactions whose parent transaction is unknown) in a pool
temporarily known as “orphan transaction pool”. Once the mother transaction is received the node
extracts the corresponding daughter transaction from theorphan transaction pool and inserts the pair of
mother-daughter transactions in their transaction pool (and of course propagate the transaction pair
through the peers with which it is connected).
There is a limit of orphan transactions that can be stored in theorphan transaction pool known as
MAX_ORPHAN_TRANSACTIONS, imposed by the system to avoid denial-of-service attacks
against individual knots. Whenever a node is saturated, the orphan transaction pool eliminates
randomly a transaction contained in it as long as the pool size is less than
maximum limit imposed.

Transaction script

Bitcoin clients validate a transaction by running a script written in the Forth scripting language.
like. Both the locking script present in UTXO and the unlocking script are written with this language
scripting. In the process of validating a transaction, the unlocking script in each input is executed
next to the corresponding locking script to check if it meets the expense conditions for
that specific input.
Today, most of the transactions processed through the bitcoin network take the form
sender pay recipient and are based on the same script called Pay-to-Public-Key-Hash script.
However, the use of scripts to lock the outputs and the addition of input rules that can remove the
lock implies that, through the use of the programming language, transactions may contain
an indefinite number of conditions.
The bitcoin transaction validation engine relies on two types of scripts to validate them
transactions: a lock script and an unlock script.
A locking script set on a specific output specifies the conditions to be satisfied for the eventuality
future expenditure of the funds contained in it. Historically, this script is known as scriptPubKey,
since it often only contains a bitcoin address or a public key, but the term locking
script is conceptually more correct because it does not refer to a specific set of conditions
expenditure (although it is the most commonly used in the bitcoin network).
An unlocking script is a script that solves (satisfies) the conditions set on a specific output from
a locking script and guarantees the possibility of spending the funds contained in it. An unlocking script is
present in every transaction input and in the vast majority of cases is a digital signature
produced by the wallet application starting from the user’s private key.
Each bitcoin client validates a transaction by executing the locking script and the unlocking script together. For
each transaction input the software searches for the corresponding UTXO which contains the lock script
which defines the conditions of expenditure. Then the software extracts the unlocking script for it
specific transaction input and executes the lock and unlock script pair at the same time.
In the original implementation of bitcoin the two scripts were concatenated and executed sequentially. For
security reasons, since 2010, this validation method has been modified to not allow
to unlock the script to modify the shared execution stack and to corrupt the lock script.
In the current implementation the two scripts are executed separately and the execution stack is
transferred between the two scripts. First the unlocking script is executed and, if its execution does not generate
errors, the script’s main stack is copied and the lock script is executed. If the output of the locking script
executed with the data stack of the unlocking script is “TRUE” the unlock script was successful and the
spending conditions are met. Recall that UTXOs are permanently registered in the
blockchain and can not be edited. Only valid transactions (which meet the
spending conditions for the specific UTXO) can mark them as spent and remove them from the list of
unspent transaction output.
The bitcoin scripting language is a stack-based language because it uses a data structure
call stack. The stack (stack) is a very simple data structure, which allows two operations:
push and pop (respectively adding and removing elements from the top of the stack).
The execution of the script processes the instructions from left to right. Operators enter or
they eliminate one or more parameters (constant data) from the stack, act on them and can optionally
keep the result of this action in the stack (the OP_ADD statement, for example, inserts two
parameters in the stack, it calculates the sum and inserts the result of the operation in the stack).
Conditional operators evaluate a condition by producing a result with a value of TRUE
(represented by the Boolean variable 1) or FALSE (represented by the Boolean variable 0).
The bitcoin scripts contain a series of conditional operators for which their output will be a value
boolean TRUE or FALSE.
The previous line represents a script containing simple arithmetic functions and an operator
conditional. Specifically, the script calculates the algebraic sum 2 + 7-3 + 1 and imposes the comparison with
the numerical value 7 producing an output of value TRUE (note that the output of the single instruction
can be used as a parameter of the next statement). The execution stack will contain
in the order the values ​​2, 7, 9, 3, 6, 1, TRUE.

In the process of validating a transaction, each combined execution of the unlocking script and the
locking script that generates an output (last parameter of the execution script of the locking script) of
TRUE value is considered valid.
The scripting language used in bitcoins contains many operators but has a limitation, not
allows the use of loops or other complex flow control methods that are not operators
conditionals. This ensures that the language is not Turing Complete, which implies that the
execution complexity is limited and the execution time is predictable.
These limitations ensure that the language can not be used to create infinite loops or
other forms of “logic bomb” that can be inserted into the lock and unlock scripts of a transaction generating a
denial-of-service against the network.
In the early years of bitcoin development the developers introduced limitations to the types of
processable scripts. These limitations were contained in the isStandard () function, which defined 5
types of standard transactions that can be performed by the system. Currently these limitations have been
deleted but persist in nodes that run the reference client. The user can therefore generate
non-standard transactions containing non-standard transaction scripts but it is necessary that the
transaction reaches a mining node that does not execute the reference client and accepts it as valid
the type of transaction in order to incorporate it into a block to be undermined.
The 5 types of standard transaction scripts are: pay-to-public-key-hash (P2PKH), pay-to-public
key, multi-signature (limited to 15 keys), pay-to-script-hash (P2SH) and data output (OP_RETURN).


Pay-to-Public-Key-Hash (P2PKH)

Most transactions processed in the bitcoin system are P2PKH transactions. They
they contain a locking script that blocks the output through the hash of a public key (address
bitcoin). The corresponding unlocking script consists of a digital signature generated by the key
private corresponding to the bitcoin address specified by the locking script.
In this type of transaction the locking script contained in the transaction output has the form:
OP_DUP OP_HASH160 <Public Key Hash Receiver> OP_EQUAL OP_CHECKSIG
The unlocking script present in the transaction input has the form:
<Receiver Signature> <Receiver Public Key>
The two combined scripts form the validation script in the form:
<Receiver Signature> <Receiver Public Key> OP_DUP OP_HASH160
<Receiver Public Key Hash> OP_EQUAL OP_CHECKSIG
If the output of the combined script is TRUE, the transaction is considered valid by the system.



Pay-to-public-key is a simpler bitcoin transaction than pay-to-public-key-hash.
The public key is stored in the lock script and not its hash. Pay-to-public-key is often
found in coinbase transactions generated by mining nodes that run a software client
The locking script in this type of transaction has the form:
<Receiver Public Key> OP_CHECKSIG
The corresponding unlocking script has the form:
<Signature from Receiver Private Key>
The combined script, executed in the transaction validation process, has the form:
<Signature from Private Key Receiver> <Receiver Public Key> OP_CHECKSIG
If the output of the combined script is the Boolean value TRUE, the transaction is considered valid.


Multi-Firma (Multi-Signature)

The multi signature script sets a condition for which N public keys are stored in the
lock script and requires at least M corresponding digital signatures for the unlock script (in one
M-of-N scheme in which N is the total number of keys and M is the threshold of signatures required for the
validation of the transaction).
The maximum number of public keys that can be listed in the lock script is currently 15.
The general form of a lock script that sets a multi-signature M-of-N condition is:
M <Public Key 1> <Public Key 2> … <Public Key N> N OP_CHECKMULTISIG
where the parameters M and N have the meaning previously described.
The corresponding unlocking script has the general form:
OP_0 <Signature 1> <Signature 2> … <Signature M>
The prefix OP_0 is due to a bug in the implementation of CHECKMULTISIG. It is ignored
from the operator and is simply a placeholder parameter.
The combined script will have the general form:
OP_0 <Signature 1> <Signature 2> … <Signature M> M <Public Key 1> <Public Key 2> … <Public
The combined script will return TRUE if, and only if, the unlock script matches the set conditions
from the lock script.


Data Output (OP_RETURN)

Bitcoin’s blockchain has technological potentialities that are not limited to the registration of
currency transactions. Many developers have tried to use the script language of
transaction for applications such as digital notary services, certificate and smart storage
Using the scripting language for these purposes created transaction outputs that contain al
their internal data and not just expendable currency units.
This alternative use of bitcoin blockchain technology has created controversy within
of the community above all for the burden, in terms of storage space, that it entails.
In the 0.9 release of the bitcoin reference client, the OP_RETURN operator was introduced
allows a maximum of 80 bytes of data to be inserted into a transaction output. It generates
a non-expendable output and should not be stored in the UTXO pool but only in the blockchain.
The structure of a data output script is as follows:
OP_RETURN <date>
There is no corresponding unlock script because the OP_RETURN operator generates non-output
spendable. Its only function is to store a data set in the public register blockchain.
A standard transaction can only contain a transaction output of type data output and it must
necessarily be combined with any other type of output to generate a transaction


Pay-to-Script-Hash (P2SH)

The pay-to-script hash (P2SH) was introduced in 2012 to simplify the use of complex scripts
of the transaction. It is often used to make multi-signature transactions more efficient.
Although multi-signature scripts are a powerful feature, they present difficulties
use. The sender must use a bitcoin wallet enabled to generate transactions containing
custom script, must know the scripting language and must be communicated by the recipient
information needed to generate the script (public key set and number of
private keys). The resulting transaction will also be larger than the classical one
pay-to-public-key hash operation that weighs on the sender in terms of transaction fees.
P2SH transactions perform transactions with multiple signatures similar to a traditional P2PKH transaction
(the destination address has the initial character number 3 and not the number 1) and shifts the burden of
generation of the script by the user to the recipient. In detail, the sender specifies in the blocking script
the ransom script hash (obtained with the double hash function via SHA-256 and algorithms
RIPEMD-160) of a size equal to 20 bytes. The block script therefore has the general form:
OP_HASH160 <ransom script hash> OP_EQUAL
The corresponding unlock script (for a multi-signature M-of-N scheme) will take the form:
<Sig1> <Sig2> … <SigM> <M PK1 PK2 …. PKN N OP_CHECKMULTISIG>
In the transaction validation procedure the two scripts are combined in two phases. The first phase
provides that the redemption script contained in the unlock script is compared to the contained hash
in the block script:
<M PK1 PK2 …. PKN N OP_CHECKMULTISIG> OP_HASH160 <redemption script hash>
In the event that the two hashes match, the unlock script is executed:
<Sig1> <Sig2> … <SigM> M PK1 PK2 …. PKN N OP_CHECKMULTISIG


Credits: Andrea Mineo

  • Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam

21st april 2014 2:13am
Hello there
Did you check out Pages framework ?
Its an awesome chat

Press enter to search :D

Pages Search Results